OAuth 2.0 Grant Types

OAuth 2.0 has become the de facto standard to handle access to user data and resources in modern applications. This protocol allows third-party applications to attain limited access to a user's resources on any other service such as Google or Facebook without having to share the password of that service. In order to support attaining such limited access to resources in various scenarios and for different purposes, OAuth 2.0 utilizes various "grant types.". In this blog, we'll do a deep dive into the OAuth 2.0 grant types-world: what they are, why you should use them, and their common pitfalls.

Authorization Code Grant

The Authorization Code Grant is the most used grant type for OAuth 2.0. It was initially designed for applications that can keep a client secret on their server. This is a flow between three parties: the user, the resource server, and the third-party application requesting the resource, often called the client.

• The user wants to access its resources on resource server hypothetically as the client application.

• The client application sends the user to an endpoint of the resource server (the authorization point), logs in, and gives permission.

• Authorization Code sends an authorization code to the user that then returns it back to the client application.

• The client app exchanges the authorization code for an access token at a resource server's Token Endpoint using their credentials (client ID and secret).

Implicit Grant

The Implicit Grant is intended for clients that cannot store a client secret securely. This includes, for example, clients implementing the client in a browser using JavaScript or mobile applications. Because there's no authorization code exchange in this grant type, it is way simpler: an access token is issued right when the user authorizes the client.

• The user is logged in to the client application and tries to access their resources on Resource Serer.

• User is sent to authorization end point of a resource server by the client application and they log in, grant permission etc.

• Resource-server will return access-token client application so user returned that access token from the resource server.

Security Note: The Implicit Grant is less secure as the access token can appear in user browser history or when sharing URLs and should only be used if all data over that connection will classify what you have to protect from exposure.

Password Grant (Resource Owner Password Credentials)

A more specific implementation of this type, known as the Resource Owner Password Credentials Grant is meant for instances where trust in an application can be assembled (like first-party applications or internal tools). This grant type enables the user to fetch an access token for a client application by collecting their user credentials (username and password) on the resource server side directly. The user provides resource server credentials to the client application.

• The client application asks for an Access Token with the Resource Server, sending in both its Client Credentials (also identifying itself as a client by informing it's own Application ID) and also User Credentials.

Security Note: This is a grant type that should be used with caution for the reason that it involves giving out your password to client application which ultimately make you be on risk in terms of phishing or other kinds of attacks.

Client Credentials Grant

The Client Credentials Grant is basically used when a client communicating directly with the Resource Server i.e without user interaction. This grant type allows the client application to be granted an access token based on its own credentials (client ID and secret).

• The client application requests an access token from the resource server, including its client credentials.

• The resource server validates the credentials and issues an access token.