OAuth 2.0 which is a successor of OAuth 1.0 is a widely used authorization framework (sometimes referred as authorization protocol) which enables third party applications to access protected resources from resource servers on behalf of resource owners in a secured, reliable manner.
In this post, I will explain how OAuth works, what are different OAuth roles and what are different grant types available in OAuth authorization framework.
What is OAuth 2? Introduction to OAuth Framework
As stated above, OAuth 2.0 is an authorization framework for enabling resource sharing in a secured manner through a sequence of steps where resource owner permits a client application to a certain protected resource for a limited time.
If you prefer to read about OAuth authorization mechanism in text format–Continue reading below tutorial.
OAuth framework enables client applications by using delegation pattern in which certain functionalities can be delegated to an existing resource server without replicating the same feature E.g. if you are using an application which wants to access some files on a Google Drive, such access can be given through OAuth based authorization. In similar way, if you visit a website which provides you option of single sign-on, you may simply utilize your existing Facebook, Google or Twitter account through OAuth based authorization and then continue using that site without signing up with a separate account on that site.
When we talk about OAuth authorization framework, there are multiple roles associated with it which come into the picture during a series of steps that take place during authorization process.
Below are the major OAuth Roles:
Resource owner is the user who actually owns protected resources on any resource server. E.g. If you own certain files on Google Drive, you are the resource owner for those protected files. If you have an account on Twitter, Facebook or Gmail, you are the resource owner for the data that belongs to that account.
Resource owner is among the primary roles in OAuth flow as any authorization can not be granted without consent of resource owner.
Client application is third-party application (website, mobile-app or even a desktop app) which is registered already with an authorization server and requests access to protected resources on a resource server on behalf of a user (resource owner).
E.g. when you visit a website abc which prompts you to grant access to your profile information on Twitter; that website abc will be considered as client in this OAuth flow.
Authorization server is responsible for providing authorization grant and access tokens to the client on behalf of a resource owner.
Its important to understand that authorization server issues access tokens on behalf of a user only once user has been authenticated first.
Resource server is the server that hosts the protected resource for a resource owner. Any protected resources on a resource server are accessible only to the resource owner once authenticated or to any client application which has been granted access by the resource owner by getting access token issued through authorization server.
OAuth Flow Diagram
All the OAuth roles explained above, take part in the sequence of events that take place for authorization using OAuth framework. Actual sequence of steps and low level details may vary depending on grant type, but in general, below is the high level flow for OAuth authorization framework:
OAuth Grant Types
OAuth 2.0 framework provides various grant types–each serving a specific use-case.
Below are the most common grant types associated with OAuth framework:
OAuth Grant Type: Authorization Code
Authorization Code grant type is considered as the most secure grant type. In this type of grant, Client first gets authorization code from Resource Server before requesting access token from authorization server.
In this grant type, client first accesses authorization server by redirecting the user. Following parameters are sent (query parameters) in this case to authorization server:
response_typecontaining the value
client_idwith the client identifier which is unique for a client.
redirect_uriwith the client redirect URI. This parameter is optional, but if not send the user will be redirected to a pre-registered redirect URI.
scopea space delimited list of scopes
On Authorization server, the request is validated for all the above parameters and user is asked to login (if not already logged in) and then user is prompted to approve the request sent from the client.
Once user has approved client request, a redirection takes place back to the client application on specified redirect URI along with grant code (and an optional state value).
Now as second part of this flow, client applications sends a POST request to same authorization server in order to request an access token.
This POST request from client to the authorization server contains following important elements:
grant_typewith the hard-coded value
client_idwhich is the client’s unique identifier
redirect_uriThis will be same redirect URI the user was redirect back to
codeThis will be same authorization code which was sent from authorization server to call back URI in query parameters.
Once authorization server receives and validates the above POST request, he authorization server will respond with a JSON object containing the following properties:
token_typethis will usually be the word “Bearer” (to indicate a bearer token)
expires_inwith an integer value mentioning when the token will expire
access_tokenthe access token itself
refresh_tokena refresh token that can be used to acquire a new access token when the original expires
OAuth Grant Type: Implicit
Implicit grant type differs from authorization code grant type based on the sequence of steps as no authorization code is returned from the authorization server and access token itself is directly issued once client’s authorization request is validated and approved.
Implicit authorization grant type is used in user-agent (browser) based clients and for mobile application scenarios where client secrets can’t be safely stored with client side code easily accessible.
OAuth Grant Type: Resource Owner Password Credentials
This grant type is used only when client application is completely trusted (e.g. internal or self-hosted client) as in this case, user is asked to provide its credentials (username and password) and once user has provided its credentials, client application itself requests access token from authorization server by sending a post request containing below information:
grant_typewith the hard-coded value
client_idwith the the client’s unique ID
client_secretwith the client’s secret
scopewith a space-delimited list of requested scope permissions.
usernamewith the user’s provided username
passwordwith the user’s provided password
Once authorization server validated above POST request, It will return access token and other related information in same way as in case of authorization code grant type.
OAuth Grant Type: Client Credentials grant
This grant type doesn’t involve a separate resource owner role as client application itself plays dual role of a client as well as resource owner and requests for an authorization to protected resource which are under the ownership of client itself.
This grant type is mostly used for server to server authorization where no external user is involved.