Gokdag Goktepe
Cloud Engineer, Developer, A life long learner

Introduction to OAuth 2.0 Protocol

“It’s a dangerous business, Frodo, going out your door.”

This article is the first one of the OAuth 2.0 protocol article series. It holds a value as an introduction to the topic. I start with briefly highlighting the differences between authentication and authorization and where the OAuth 2.0 protocol fits within these components. I then provide the implementation domain of the protocol and continue with the definition of the protocol’s essential concepts. At the end I briefly describe the problem that the OAuth protocol solves and hint at the forthcoming contents for this article series.

Table of Contents

1. Authentication Vs. Authorization
2. OAuth 2.0 Protocol
3. The Problem OAuth 2.0 Protocol Solves
4. The Road that paved the way for OAuth Protocol
5. What is next?
6. Conclusion

Authentication Vs. Authorization

Authorization and authentication are most of the time two bottlenecks of modern software applications. They present security concerns and should be designed and implemented carefully.

Authentication is the process of proving your identity to third party services. It is the process of verifying who someone is. In its simplest form you sign up to an application by providing your credentials and use these credentials ( most of the time an email address and a password ) to log in back to the application.

On the other hand authorization is the process of giving someone or another application permission to do something or to have something, verifying what specific applications, files, and data a user or a client has access to. Most of the cases, permission is given by an application on behalf of you or on behalf of the resource owner to another application to use its resources. For example as a user you want to login to Spotify using Facebook. In this case Facebook is giving access to your resources in Facebook, with your consent, to Spotify.

An authorization happens after only a successful authentication process. This is where OAuth 2.0 comes into play; during the authorization process.

OAuth 2.0 Protocol

OAuth 2.0 is an industry-standard protocol for authorization developed and maintained by IETF (Internet Engineering Task Force). The OAuth 2.0 authorization framework provides authorization flows for web, desktop and smart-home applications.

For cloud native applications OAuth 2.0 has a broad implementation domain. Pretty much every cloud provider has close integration with this industry standard authorization protocol. You can use AWS Cognito, Azure Active Directory, Google Cloud authentication services or Kubernetes OAuth Proxy ingress controller together with OAuth 2.0 protocol. Even most of the API calls on services of these cloud providers use the protocol.

From the perspective of the user, it simply allows users to grant websites and applications access to their information without giving their passwords.

As opposed to the general belief where a person or a user is generally authorized, most of the authorization processes in fact happen in between machines, services and applications. Considering the interconnected API swarm of the cloud and the importance of microservices this can only be natural. OAuth 2.0 is most of the time positioned in between these authorization processes.

In more technical level, as it is defined in RFC 6749 , OAuth 2.0 enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource-owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

For the sake of further reference and simplicity it is time to clearly define the roles OAuth uses as it is stated in RFC documentation:

resource owner

An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.

resource server

The server that is hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

client

An application making protected resource requests on behalf of the resource owner and with its authorization. The term “client” does not imply any particular implementation characteristics (e.g.,whether the application executes on a server, a desktop, or other devices).

authorization server

The server that is issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

Since now we saw the stakeholders from the perspective of OAuth, to build a comprehensive understanding of OAuth we can now highlight what was the problem before OAuth took place. And how it intends to solve these problems.

The Problem OAuth 2.0 Protocol Solves

In the traditional client-server authentication model if the client wants to use some of the server resources it has to do so by providing the resource owner’s credentials. But it creates myriad different problems and limitations.

• Clients (or third-party applications) are required to store the resource owner’s credentials for future use. Typically a password in clear-text.
• Servers have to support password authentication which is a security weakness on its own.
• Third-party applications ( servers, clients, etc… ) gain broad access to the resource owner’s protected resources, leaving resource owners without ability to restrict duration or access to a limited subset of resources.
• Resource owners cannot revoke access rights of the individual third parties without revoking access to all third parties.
• Compromise of any third-party application results in compromise of the end-user’s credentials and all the resources protected by these credentials.

OAuth addresses these issues by abstracting the authorization layer and separating the role of the client from that of the resource owner. Any access request from a client issued with a different set of credentials than those of the resource owner.

These different sets of credentials are defined as an access token which denotes a specific scope, lifetime, and other access attributes. These tokens are issued by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.

OAuth can be complicated to understand at times if you are not familiar with the authorization flow. It can even be more complicated to implement within an application as an authorization layer. No worries though, we will explain the OAuth2.0 authorization flow with its different components when the time is right.

The Road that paved the way for OAuth Protocol

Different types of authorization flows that have tried to solve the problem of the user giving her consent to a client for accessing some of her resources on another server. Before OAuth protocol, HTTP Basic Authentication was the industry standard covering both authorization and authentication at the same time. The dawn of authorising third party applications started by Yelp. Flickr tried to solve the problem with its API called FlickrAuth that used “frobs” and “tokens”. Google’s own implementation was AuthSub. Yahoo! created BBAuth which is short for a browser based auth. Facebook did not move a lot and just used MD5 signed requests.

HTTP Basic Authentication

HTTP Basic Authentication was in use for some time. It mostly depended on client-server architecture where clients make requests to the resource server with username and password. RFC 7235 defines the HTTP Authentication framework. The framework’s authentication flow is called challenge and response flow. Particularities of the HTTP Basic Authentication scheme are also defined in RFC 7617 as an extension to RFC 7235.

Here how the HTTP Basic Authentication challenge and response flow works:

• Client makes a HTTP request to a server.
• Server responds to a client with 401 (Unauthorised) response status together with information on how to authorise with a WWW-Authenticate response header.
• Client then makes another request with Authorization request header with the credentials. The credentials are usually taken from the user by the client with a password prompt.

There are several drawbacks to this flow. The password is sent over the wire in base64 encoding which can easily be converted to plain text. Also in each request password is repeatedly sent causing a larger attack window. The password is also cached by the web browser leaving the CSRF (Cross Site Request Forgery) attack possibilities wide open. You can of course use SSL and make your request over HTTPS however even though the password is safe during transit it will be stored or transferred somewhere else in plain text.

The real problem with this method is actually during the authorization of third-party applications to gain access to resource servers. Client has to collect user credentials in plain text and administer challenge and response flow with all aforementioned drawbacks. At the end, the application will gain full access to the account. There is no limiting the access to designated resources. Users can only revoke access by changing the password and as a user you never know if the client is vulnerable to attacks or it will do additional things to your account. This is how Yelp was working.

FlickrAuth

Later on Flickr came with an auth api called FlickrAuth. Authentication and authorization was being served from the same API.

As you can see from the diagram, FlickrAuth was asking the user’s permission on its own rather than asking the client the user name and the password. Therefore there is no need anymore for a third-party client to store the user’s credentials. Instead client uses auth token to access user’s resources in resource server.

FlickerAuth had similarities with OAuth however there were also a lot of shortcomings.

First of all if the api key is somehow leaked or exposed any malicious client can ask for auth token. There is no way for the server to know if the client is genuine one or not. There was no equivalent of an api secret. Api key was public to developers and the like.

Secondly FlickrAuth was giving the client permission on the whole level. Account level access was only read, write or delete. Therefore any client who had the consent of the user had ultimate accessibility over all resources the user had. Neither resource level restrictions nor scope were in place.

Third, the FlickrAuth was giving the auth token for an unlimited time. Once you are in you are always in. At any moment in time if the auth token is stolen the only way to revoke all access is to revoke the third-party client from your consent list. Of course if you are lucky enough to know that the auth token was compromised.

Google AuthSub

Similar to FlickrAuth, Google as well tried to solve the third party application authorization problem with an auth token with an authorization API called AuthSub.

AuthSub flow also starts like FlickrAuth. Once user initiates to give permission to the client, the client constructs the appropriate AuthSub URL and then sends the user to that URL so they can log in; the AuthSub sends the user back to URL on client’s site that the client specified, and returns a one-time-use token; client optionally exchanges that token for a session token; then client sends the token in the Authorization header with each request that the client sends to the service.

Authorization flow was improved in contrast to FlickrAuth in several areas. First one was in the “application identity” domain. Application identity is the identity of the client that can be confirmable by authorization server. In FlickrAuth all we could use was the “api key”. In AuthSub however, the client had to create a self-signing RSA private key and public certificate in addition to registering the client application to the server.

Second was an improvement on the scope level. In authorization terminology “scope” determines the token access to the user’s data. You can define the scope as such that at the end you can restrict access to some resources of the user and allow some others.

Another improvement was on the time that the token can be valid. AuthSub provided two options. One was single-use token in which an access to the resource can happen only once and the other one was session tokens which was providing unlimited time of access. Alas an unlimited session token posed several security risks while storing the token on cookie level. Regardless, the single-use token concept was there to prove a good point.

Yahoo! BBAuth

Yahoo developed BBAuth (Browser Based Authentication) more or less at the same time like Google. And the flow is also more or less the same. The below schema can briefly explain the flow. The first time a user visits the third party web application, the web application redirects the user to a specially constructed Yahoo! URL where the user can login and grant the third party application permission.

As the name suggests BBAuth was only supporting web based applications and until OAuth none of the above was supporting desktop or mobile applications.

The Protocol That is Needed

Before OAuth came to existence there were also some other efforts to solve third-party authorization problems. Those I have mentioned above are only some of the significant ones. However, I believe, it is enough to prove the point that all of those above tried to solve the same problem on a proprietary level. But at the end their needs were the same.

The first need is that any authorization server needs to know the identity of the third-party application. Most of the time as a third-party application developer it is not enough to register yourself to the authorization server and receive an api-key. Api-keys in nature are more prone to be shared, stolen or lost. In these cases authorization servers cannot really be sure who is making the request. Therefore “application identity” is one of the first challenges of any authorization flow.

As we can see above authorization flows another challenge is how to restrict resource access even though the third-party application earned to have auth-token. Restricting access on read-write-delete level, on selective resource level or on time/expiration level poses another challenge on its own. “Scope” parameter was one of the first examples of its kind.

These challenges and needs in mind all these developers realized the common goal and came together. By 2007, the first draft of OAuth1 was published and it was deployed at several companies.

What is next?

In the forthcoming article we will see the differences between OAuth 1.0 and OAuth 2.0 and which specific improvements have been made and what possible risks and problems we are still facing. We will then discuss why OAuth 2.0 goes hand in hand with OpenId as an Authentication/Authorization duo. At the end we will see several OAuth2 implementations of AWS Cognito.

With AWS Cognito and using OAuth protocol you can easily trigger authorization flow for your applications, secure api gateways and provide authorization for your IoT devices.

Conclusion

OAuth protocol streamlines the third-party access request of users or clients. It provides open and safe architecture for authorization. It ensures the security of the resource owner’s credentials and minimize the attack vector. It is widely used authorization framework for cloud providers and cloud native applications.