An Introduction to OAuth 2.0

What is OAuth all about?
OAuth is an open standard to authorization. OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user).
In OAuth, instead of using the resource owner’s credentials to access protected resources, the client obtains an access token, a string denoting a
specific scope, lifetime, and other access attributes.
Access tokens are issued to third-party clients 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.
Roles in OAuth
- Resource Owner: An entity capable of granting access to a protected resource.
- Resource Server: The server 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.
- Authorization server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
OAuth Protocol Flow
The figure illustrates the abstract OAuth 2.0 flow interaction between the four roles.

Authorization Grant
An authorization grant is a credential representing the resource owner’s authorization (to access its protected resources) used by the client to obtain an access token.
OAuth 2.0 specification defines four grant types.
- Authorization code
- Implicit
- Resource owner password credentials
- Client credentials
Authorization Code Grant
Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server. The resource owner is then redirected back to the client with the authorization code which the client will capture and exchange for an access token in the background. Since this is a redirection-based flow, the client must be able to interact with the resource owner’s user-agent and receive incoming requests (via redirection) from the authorization server.

Implicit Grant
The implicit grant type is similar to the authorization code grant type. However, unlike the authorization code grant type, it will be redirected along with an access token instead of an authorization code. The implicit grant type does not authenticate the client and instead relies on the presence of the resource owner and the registration of the redirection URI.

Resource owner password credentials Grant
Instead of redirecting the user to the authorization server, the client itself will ask the user for the resource owner’s username and password. The client will then send these credentials to the authorization server along with the client’s own credentials

Client Credentials Grant
The client can request an access token using only its client credentials with this grant type. It is similar to the resource owner password credentials grant type except, in this case, only the client’s credentials are used to authenticate a request for an access token.

Usage of each Grant Type
- Authorization Code Grant: when the resource owner is a user and the client is a website.
- Implicit Grant: for clients that are not capable of keeping the client’s own credentials secret
- Resource owner password credentials Grant:
— where the resource owner has a trust relationship with the client
— where the client can obtain the resource owner’s credentials - Client Credentials Grant: to invoke resources which are not specific to a particular user
I hope this article will help you to understand the basic concepts in OAuth 2.0. For more details, you can refer to the specification.
Thanks for reading. 👍 👍