Understanding OAuth 2.0

In a traditional client-server authentication model, a resource owner shares their credentials with the client so that the client can access its resources when necessary. The client does that by passing the resource owner's credentials to the resource server, and the resource server validates the same before providing access to the protected resource(s). Simple, right? 

Well, there are a bunch of problems associated with this model, a few of which are listed below:

• The client needs to store the resource owner's credentials for future use
• If the resource owner has multiple clients, the same credentials need to be distributed to all of them
• The resource owner cannot easily revoke access of just one client, as it will require all its clients to update their DB with the resource owner's new credentials 
• If one client's DB gets compromised (and hence, the resource owner's credentials), it impacts all the clients
• There is no easy way to restrict the clients to only a subset of resources of the resource owner, thus giving them overly broad access

OAuth 2.0 framework resolves these by introducing an authorization layer that eliminates the need for the client to have the same credentials as the resource owner and instead lets them access the resource owner's resources using an access token. 

For example, an end user (resource owner) can grant a document printing service (client) access to their documents (resources) stored in a document server (resource server) without sharing their credentials with the document printing service. Instead of sharing their credentials, the end user can approve the client's document access request by confirming the same with another party (authorization server) that is also trusted by the document printing service. In return, the authorization server shares an access token with the document printing service for accessing the end user's documents in the document server. 

OAuth Roles

1. Resource Owner - The entity that owns the resources. It is capable of granting access to resources
2. Resource Server - The entity that hosts the protected resources. It is capable of denying or allowing access to the protected resources of the resource owner(s)
3. Client - The entity that seeks access to (and acts on) the protected resources 
4. Authorization Server - The entity that coordinates authentication and authorization

Protocol Flow

     +--------+                                +---------------+
     |        |--(A)--I Need document access-> |   End         |
     |        |                                |   User        |
     |        |<-(B)-Ok, Granted you access--- |               |
     |        |                                +---------------+
     |        |
     |        |                                +---------------+
     |Document|--(C)Yay, I got a grant!------->| Authorization |
     |printing|                                |     Server    |
     |service |<-(D)-Cool, here's your Token --|               |
     |        |                                +---------------+
     |        |
     |        |                                +---------------+
     |        |--(E)Hey, check out this token->|    Document   |
     |        |                                |     Server    |
     |        |<-(F)Cool, here's the document -|               |
     +--------+                                +---------------+

1. Client requests the resource owner for granting access to a variety of resources. Either the client asks the resource owner directly for it (as shown above) or uses the authorization server as an intermediary (recommended - see below). 
2. The resource owner responds by returning something called an authorization grant. The resource can choose to respond with one of the four different authorization grant types or with an extension grant type. 
3. This grant is then used to request the authorization server for an access token.
4. The authorization server validates the grant and, if valid, responds with an access token (and optionally, a refresh token as well).
5. The client uses this access token to request a resource to the resource server.
6. The resource server validates the token and, if valid,  serves the request. 

Authorization Grant

This is a credential that represents the resource owner's authorization provided to a client to access its protected resources. As discussed earlier, this is shared with the authorization server to get an access token in exchange. There are four authorization grant types:

Authorization Code

     +----------+
     | End      |
     | User     |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier      +---------------+
     |  End    -+----(A)-- & Redirection URI ---->|               |
     |  user's  |                                 | Authorization |
     |  User-  -+----(B)-- User authenticates --->|     Server    |
     |  gent    |                                 |               |
     |         -+----(C)-- Authorization Code ---<|               |
     +-|----|---+                                 +---------------+
       |    |                                         ^      v
      (A)  (C)                                        |      |
       |    |                                         |      |
       ^    v                                         |      |
     +---------+                                      |      |
     |         |>---(D)-- Authorization Code ---------'      |
     |Document |          & Redirection URI                  |
     |Printing |                                             |
     |Service  |<---(E)----- Access Token -------------------'
     +---------+       (w/ Optional Refresh Token)

An authorization server is an intermediary between the client and the resource owner. Instead of the client seeking a grant directly from the resource owner, the resource owner is redirected to the authorization server, where the resource owner is authenticated. Once successfully authenticated, the resource owner is redirected to the client along with the authorization code.

There are a few advantages to this grant type.

1. The resource owner's credentials are never shared with the client since the resource owner is authenticated by the authorization server
2. The access token is transmitted directly to the client without passing it through any party, including the resource owner

Implicit

     +----------+
     | End      |
     | User     |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |  End    -+----(A)-- & Redirection URI --->|               |
     |  user's  |                                | Authorization |
     |  User-  -|----(B)-- User authenticates -->|     Server    |
     |  Agent   |                                |               |
     |          |<---(C)--- Access Token -------<|               |
     |          |                                +---------------+
     |          |  
     |          |                               
     |          |
     |          |       
     |          |                               
     |     (F)  |
     |          |                                
     +-|--------+
       |    |
      (A)  (D) Access Token
       |    |
       ^    v
     +---------+
     | Document|
     | Printing|
     | Service |
     +---------+

In this grant type, there is no intermediate credential like an authorization code. This means, once the resource owner is authenticated by the authorization server, an access token is immediately made available to the client. This is definitely faster than the authorization code grant type but has security implications (like potential exposure of the access token to the resource owner or other applications with access to the resource owner's user agent). This grant type is not recommended when the authorization grant type is available. 

Resource Owner Password Credentials

     +----------+
     | End      |
     | User     |
     |          |
     +----------+
          v
          |    End User's
         (A) Password Credentials
          |
          v
     +---------+                                  +---------------+
     |         |>--(B)---- End User's ----------->|               |
     | Document|         Password Credentials     | Authorization |
     | Printing|                                  |     Server    |
     | Service |<--(C)---- Access Token ---------<|               |
     |         |    (w/ Optional Refresh Token)   |               |
     +---------+                                  +---------------+

In this grant type, the resource owner's credentials are used by the client to obtain an access token for the first tike. Once the access token is available for subsequent resource requests, the access token is used. This eliminates the need to store the resource owner's credentials at the client's end. This is useful where the resource owner has a trusted relationship with the client. This grant type is not recommended when the authorization grant type is available.

Client Credentials

     +----------+                                  +---------------+
     |          |                                  |               |
     |          |>--(A)- Client Authentication --->| Authorization |
     |End User's|                                  |     Server    |
     |   app    |<--(B)---- Access Token ---------<|               |
     |          |                                  |               |
     +----------+                                  +---------------+

This grant type is used for cases where the client controls the resources, or they are the resource owners too. In this case, the client's credentials (shared with the authorization server beforehand) are used as an authorization grant to obtain the access token. 

There is an extension grant type too, which is an extensibility mechanism to create more grant types. It is out of scope of this article. 

Access Token

An access token is a credential used to access protected resources of the resource owner hosted by the resource server. It is a simple string that self-contains critical authorization information which is secure and verifiable. This also contains the scope and access time for the requested resources, which can be enforced by the resource server and/or the authorization server. Often, these tokens are signed, which also helps the resource server to verify the identity of the client. 

For every resource request, the access token is sent to the resource server along with the other request properties. The structure of this token is implementation specific and is not dictated by the OAuth 2.0 specifications. Read this for an example access token format. 

Refresh Token

  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  |Document|                            |  Server  |   |     Server    |
  |Printing|--(E)---- Access Token ---->|          |   |               |
  |Resource|                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

This is another credential that is used by a client to obtain access tokens from the authorization server when the current access token expires or becomes invalid. This is at the discretion of the authorization server to issue a refresh token.

OAuth 2.0 is an extremely rich authorization framework which has multiple implementations available in the market today. It has proven to be secure and has stood the test of time which is evident from its adoption in numerous organizations in the recent times. In a future tutorial, we will dive deeper into the framework with some working examples.