Grant type

Make sure that you understand the OAuth terminology before proceeding!

Common grant types

The OAuth framework specifies several grant types for different use cases. Below are the and most uses grant types.

  • Authorization code - Used for server-side web apps, involves redirecting the user to obtain an authorization code. See details
  • Authorization code with PKCE - Proof Key for Code Exchange RFC 7636 is an extension to the Authorization Code flow to prevent CSRF and a secure way to authenticate single page applications or native applications to access your API. See details
  • Client Credentials - For machine-to-machine authentication, the client directly authenticates with the server, its does not involve with users interactions. See details
  • Password - Allows trusted first-party clients to collect user credentials for authentication without having user to manually authorize the login request. See details
  • Refresh token - Gives client the ability to refresh an access token without having user to re-login. See details

Choosing a different grant type

A grant is a method of acquiring an access token. Deciding which grants to implement depends on the type of client the end user will be using, and the experience you want for your users.

See the below section for a full grant types terminology
Grant types diagram

Grant types terminology

Some grant types terminology used in the OAuth 2 framework is detailed here, to help you understand the nature of a client (app) and choose the correct grant to fit your use-case.

What is first party & third party client?

First party

A first-party client is an application developed and owned by the same organization as the authorization server, or one that is trusted to handle user authorization credentials securely. For example, Spotify's app, developed and owned by Spotify, is implicitly trusted due to its reputation and ownership.

Third party

A third-party client, on the other hand, is an application or service developed by a separate entity from the authorization server. These clients are considered less trusted as they are developed and maintained by external parties.

Third party native applications should use the authorization code grant (via the native browser, not an embedded browser e.g. for iOS push the user to Safari or other kind of native browser, don't use any type of embedded WebView such as iframe, WKWebViewer, ...etc).

What is access token owner?

The access token owner is the entity that possesses and controls the access token. Typically, this refers to the user whose credentials were used to obtain the access token. The access token owner grants permissions to the client application to access protected resources on their behalf.

In short: Owner is a user or a resource owner that grant access to the client (app).

What is a client type?

Depending on whether or not the client is capable of keeping a secret, you can already determine which grant the client should use.

  • If the client is a web application that has a server side component that are capable of storing the client secret securely then you should implement the Authorization code grant
  • If the client is a web application that runs entirely on the front end (e.g., a single-page web application) or a native application such as a mobile app that is not capable of securely storing the client's secret, you should implement the Authorization Code grant with PKCE

Legacy grant types

These below Grant are no longer list in the Grant type flow because it's considered as legacy approaches. This means that they are outdated or obsolete methods for obtaining access tokens in OAuth 2.0.

They may still be in use but are no longer recommended as they have several drawbacks, such as being less secure or less efficient compared to newer alternatives.

  • Password grant - The Password Grant, while still supported by OAuth 2.0, is no longer recommended for most scenarios due to security concerns and best practices. Instead, the Authorization Code Flow is strongly recommended as a more secure alternative.
  • Implicit grant - It is recommended that clients no longer use the Implicit Grant, and are recommended to use the new alternative approach, the Authorization Code grant with PKCE.
Table of Contents