What is OAuth 2.0 (Open Authorization)?

OAuth 2.0 (Open Authorization) is a standard for authorization where a user allows an application to access their resources hosted on another application, on their behalf, without the sharing of their credentials. It’s a delegated protocol, meaning that someone who controls a resource allows a software application to access that resource with their permission. In the OAuth 2.0 authorization flow, user credentials are never shared. Instead, an access token is granted and used to prove the identity.

A common example would be a user logging into an app or website using their existing credentials from another service such as Facebook or Google. The app or website doesn’t care about the user’s credentials, but just wants to know that the user is the same and has successfully logged into that service provider.

The OAuth 2.0 authorization flow and framework

Let’s use a fictitious scenario to help explain the OAuth 2.0 authorization flow.

Let’s say a user named John is using a money management application that helps him keep track of his spending across multiple accounts. Within this application, John wants to grant it access to pull his transaction history from one of his banks. Instead of John having to share his username and password with the application, it can instead use the OAuth 2.0 standard to access his user data by way of an access token. John simply needs to log into the service provider (the bank) and grant the application permission to access the bank account. An access token will be granted and used to pull the transaction history.

The OAuth 2.0 authorization framework consists of four different core roles. Let’s look at them within the context of John’s situation:

1. Client: The client is the system that is asking for access to the protected data. The client is the money management app that John is using.
2. Resource Owner: This is the user that owns the protected data and can grant access to it. In our scenario this would be John, the resource owner, who wants to grant access to his bank.
3. Authorization Server: This server, on the bank side, is responsible for authorizing John’s request and issuing an access token to access the banking data in the resource server.
4. Resource Server: The resource server protects the user data and receives access requests from the client, barring that there is a valid access token passed with it.
   

Now that we have the scenario in place and have described the four roles involved, let’s see how the OAuth flow works:

1. The client (money management app) sends an authorization request to the resource owner (John) telling him to login to the client application via an authorization server (John’s bank).
2. The resource owner is redirected to the authorization server by the client application. The client application also sends its client ID as well so the authorization server knows what application is trying to access it.
3. The resource owner logs into the authorization server, authorizes the grant to access its resources and is redirected back to the client. This redirection sends the user to a predefined redirect URI. An authorization code is also sent by the authorization server which represents the authorization.
4. The client now connects with the authorization server and requests an access token, sending the authorization code along with the client ID and a client secret.
5. If all are valid, the authorization server issues an access token to the client.
6. The client can now request a resource from the resource server and will use the access token for authentication.
7. If the access token is valid, the resource server will send the protected data to the client.

Authorization grants

OAuth 2.0 has a number of different types of authorization grants used for different scenarios and technology. The example flow above is called the Authorization Code grant and is best for server-side apps as the access token and user data isn’t sent via the browser. This is the one of the most commonly used grant types. For an overview of the other grants, take a look at our more detailed post on our blog.

OAuth 1.0 vs. OAuth 2.0

OAuth 2.0 is noted to be a complete rewrite of OAuth 1.0 and is not backwards compatible. They are best thought of as two completely different protocols. OAuth 2.0, released in 2012 two years after the release of OAuth 1.0, improves significantly in that access tokens can contain an expiration time as well as refresh tokens, there is reduced complexity in generating signatures, and having more defined roles and non-browser support. OAuth 2.0 offers more flexibility and is seen as the superior protocol of the two.