What is Authorization Grant ?

When a client applications want to access resource on a resource server, the client application must obtain authorization grant. Below are different approach to get Authorization Grant specified in OAuth 2.0.

This blog is second part of What is OAuth.

When a client applications want to access resource on a resource server, the client application must obtain authorization grant. Below are different approach to get Authorization Grant specified in OAuth 2.0.

  1. Client ID, Client Secret and redirect URLs :-
    • Application registers with Authorization Server.
    • Authorization Server provides client Id and Client Secret.
    • If application registers with multiple authorization server, each will provide unique client Id and client secret.
    • When resource owner authorizes client application successfully, it redirects to client application using redirect URI.
  2. Authorization Grant :- OAuth 2.0 lists 4 types of authorization grant as follows:
    • Authorization code :- Used by a client like web server. The authorization code grant is used to obtain both access token and refresh tokens and is optimized for confidential clients. Since this is a redirection based flow the client must be capable for interacting with resource owners user-agent and capable of receiving redirect requests from authorization server. For example web browser.
(A) The client initiates the flow by directing the resource owner’s user-agent to the authorization endpoint. The client includes its client identifier, requested scope, local state, and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied).
(B) The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client’s access request.
(C) Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier (in the request or during client registration). The redirection URI includes an authorization code and any local state provided by the client earlier.
(D) The client requests an access token from the authorization server’s token endpoint by including the authorization code received in the previous step. When making the request, the client authenticates with the authorization server. The client includes the redirection URI used to obtain the authorization code for verification.
(E) The authorization server authenticates the client, validates the authorization code, and ensures that the redirection URI received matches the URI used to redirect the client in step (C). If valid, the authorization server responds back with an access token and, optionally, a refresh token.

Image and documentation source https://tools.ietf.org/html/rfc6749
  •  Implicit:- Used by client that cannot protect secret and tokens like SPA or mobile apps. In this mode the access token is returned when the user agent is redirected to the redirect URI. The client application in this case can only send client Id to authorization server. The user agent or native application would receive the access token from authorization server. It does not support issuance of refresh token.
(A) The client initiates the flow by directing the resource owner’s user-agent to the authorization endpoint. The client includes its client identifier, requested scope, local state, and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied). (B) The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client’s access request.
(C) Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier. The redirection URI includes the access token in the URI fragment.
(D) The user-agent follows the redirection instructions by making a request to the web-hosted client resource (which does not include the fragment per [RFC2616]). The user-agent retains the fragment information locally.
(E) The web-hosted client resource returns a web page (typically an HTML document with an embedded script) capable of accessing the full redirection URI including the fragment retained by the user-agent, and extracting the access token (and other parameters) contained in the fragment. (F) The user-agent executes the script provided by the web-hosted client resource locally, which extracts the access token.
(G) The user-agent passes the access token to the client.
  • Resource Owner password:- Client or user doesn’t have access to browser. Possible use case is where user can type user name and password in the client application. The client application then uses user name and password to access resource. For example resource on Facebook or Twitter.
  • Client credential:- Used if client application doesn’t need user consent to access a resource on the resource server. For example obtaining list of venues from Foursquare.

Detailed documentation of The Authorization Framework can be found here.