Before jumping into code examples this is one of those times where the term “helicopter view” is applicable. I’m going to give a brief overview of OAuth 2.0 here, and in later articles we might go over some examples.

OAuth 2.0 – Open Authorization

OAuth 2.0 is an open standard designed to allow apps, websites, micro services and many other applications to access resources hosted elsewhere on behalf of a user. A user can grant limited permissions to these resources through their explicit consent.

An Everyday Example

You have definitely been a part of an OAuth 2.0 exchange.

As an example, let’s say you find a third-party calendar application you want to use to manage your Google Calendar. When you first set up your third-party application it prompts you to “Connect with Google” to access your calendar data. When you click connect it takes you to the Google login page
and after logging in you see a screen that lists required permissions, something like:

  • “View & edit events on your calendar.”
  • “View calendar settings.”
  • “View contacts.”

On clicking ‘Accept’, you’re redirected back to your third-party application which can now administer your calendar with the permissions you just consented to.

By the way, this real world example was a Web Application and the associated grant type used would have been an Authorization Code Grant.

There are specific grant types for each application type which I will cover further down.

OAuth 2.0 Roles

Everyone taking part in a grant type exchange takes on an OAuth 2.0 role.

Understanding these roles and how they interact helps in architecting and troubleshooting OAuth 2.0 integrations.

Resource Owner (often referred to as the User)

This is the entity that owns the data or resource being accessed. In most common scenarios, this would be an end-user. The resource owner has the capability to grant access to their protected resources.

Resource Server (often referred to as the API Server)

This is the server that hosts the protected resources. It can serve these resources to a client, provided the client has a valid access token. For example, if an app wants to fetch a user’s photos from a cloud service, the cloud service’s API that holds and serves these photos would be the resource server.

Client (often referred to as the Application)

This is the application that wants to access the resource owner’s data. It could be a mobile app, a web application, a command-line tool, etc. The client requests access tokens from the authorization server and then uses these tokens to request resources from the resource server.

Authorization Server

This is the server that authenticates the resource owner and issues access tokens to the client after obtaining proper authorization. In some setups, the authorization server and the resource server can be the same server, but for scalability and separation of concerns, they are often separated.

Redirect URI

While not a “role” in the traditional sense, it’s an essential component in the OAuth 2.0 flow, particularly in the Authorization Code Grant. It’s the URL to which the resource owner will be redirected after granting/denying permission. It’s used to deliver the authorization code or error to the client (typically a web application).

Horses For Courses

In the realm of OAuth 2.0, different “grant types” are tailored for varying authentication scenarios and offer methods for applications to obtain access tokens, each optimized for specific use cases. In parallel, OAuth 2.0 caters to diverse “application types”, from web applications, native apps, and browser-based apps to command-line tools and microservices. Each of these application types presents its unique challenges and requirements. Whether it’s a microservice needing system-to-system authentication or a command-line tool interacting directly with the end-user, choosing the appropriate grant type is akin to selecting the best horse for a particular course. It’s crucial to align the authentication method with the nature and demands of the application, ensuring a harmonious balance of security and functionality.

List Of Standard Grant Types

Here are the standard OAuth grant types,

  • Authorization Code Grant
  • Authorization Code Grant (PKCE)
  • Implicit Grant
  • Resource Owner Password Credentials Grant
  • Client Credentials Grant
  • Device Code Grant
  • Refresh Token Grant

Overview Of Standard Grant Types

Authorization Code Grant

This is typically used by server-side applications (like web applications) where the client can securely store and handle credentials. The flow involves several redirections, including getting an authorization code that’s exchanged for an access token.

Authorization Code Grant (PKCE)

(Proof Key for Code Exchange) is a significant enhancement to the Authorization Code Grant to make it more suitable for public clients, where the client cannot safely keep a client secret. It’s especially pertinent for Single Page Applications (SPAs) and native mobile apps but can indeed be applied to command-line interfaces (CLIs) as well.

Implicit Grant

Previously used for browser-based or mobile applications, this grant type returned the access token directly upon authorization. It’s considered less secure than the Authorization Code flow and is being used less frequently due to the rise of the Authorization Code flow with Proof Key for Code Exchange (PKCE) for single-page applications and mobile apps.

Resource Owner Password Credentials Grant

This involves the resource owner (user) providing their username and password directly to the client, which then obtains an access token. It’s recommended only for trusted applications, as it involves sharing sensitive user credentials.

Client Credentials Grant

Used when the client is acting on its own behalf, not on behalf of a user. The client directly requests an access token using its client ID and secret.

Device Code Grant

Designed for devices that either don’t have a browser or have limited input capabilities (e.g., smart TVs). The user completes the authorization on a separate device, like a smartphone or computer.

Refresh Token Grant

This isn’t a method to initially obtain an access token but rather to get a new access token when the current one expires. It uses a refresh token, which is usually long-lived and can be used to renew a short-lived access token without needing the user’s intervention again.

Recommended Grant Types Per Application Type

Web Applications (Confidential Clients)

  • Authorization Code (preferably with PKCE – Proof Key for Code Exchange)
  • Client Credentials (for machine-to-machine interactions without user context)
  • Resource Owner Password Credentials (less recommended due to security concerns; only if other methods are not viable and there’s high trust between the app and user)

Native Apps (Public Clients, e.g., mobile or desktop apps)

  • Authorization Code with PKCE
  • Device Code (for devices without browsers or with limited input capability)

Browser-based Apps (Public Clients, e.g., Single Page Applications)

  • Authorization Code with PKCE
  • Implicit (less recommended due to security concerns; Authorization Code with PKCE is preferred)

Command-line Tools

  • Authorization Code with PKCE (the tool can spin up a local web server to capture the code or instruct the user to copy-paste the code)
  • Device Code (suitable for tools running on devices without browsers)


  • Client Credentials (for machine-to-machine interactions without user context)
  • JWT Bearer Token Grant (specific scenarios, especially in federated security environments)

Device Flow (for devices without a browser or with limited input capability)

  • Device Code

OAuth2.0 Out In The Wild

Popular Internet Services & Supported Grant Types

Authorization Code Grant

  • Google: Google’s OAuth 2.0 implementation for authenticating users to various services like Google Drive, Google Calendar, and more predominantly uses the Authorization Code Grant.
  • GitHub: Used for applications that want to access a user’s GitHub account.
  • LinkedIn: For applications accessing user data on LinkedIn.
  • Microsoft (Azure AD): Used for applications needing access to Microsoft services like Office 365, Outlook, etc.
  • Reddit: Primarily uses the Authorization Code Grant for third-party applications that want to access a user’s Reddit data. This is the most common method for web applications or mobile apps that need to operate with user-specific data or actions on Reddit.

Implicit Grant

  • This grant type was once popular for Single Page Applications (SPAs), but due to security concerns, its usage has been discouraged. The Authorization Code Grant with PKCE has become the recommended approach for SPAs.
  • Spotify: Historically, Spotify’s Web Playback SDK used the Implicit Grant, although they might have shifted strategies since.
  • Reddit: Historically, Reddit also supported the Implicit Grant, especially suitable for applications that run directly on a user’s device, such as browser-based apps. However, as with other platforms, due to security concerns, the Authorization Code Grant (potentially with PKCE) is often recommended over the Implicit Grant.

Resource Owner Password Credentials Grant

  • This grant type is generally used by applications that have a high degree of trust with the user. Its usage is discouraged unless other flows are not viable.
  • Some older or legacy systems may still use this, especially those transitioning from older authentication mechanisms to OAuth 2.0. Specific large-scale examples are less common due to the security implications.
  • Reddit: Supported this for script applications that only need to access the account of the developer (like bots operating on behalf of a single user). However, as a best practice, it’s advisable to be cautious with this grant type due to its inherent security risks.

Client Credentials Grant

  • Microsoft (Azure AD): For service-to-service calls that require access tokens but not user consent.
  • Slack: When building internal integrations or bots for Slack, the Client Credentials Grant may be used to obtain an app-level token.

Device Code Grant

  • Google: Used for limited input devices like smart TVs or IoT devices where typing a full set of credentials is cumbersome.
  • Microsoft (Azure AD): Supports this for situations where the device doesn’t have a browser or has limited input capability.

Refresh Token Grant

  • Refresh tokens are generally supported by services that utilize the Authorization Code Grant to extend the life of the user’s session without requiring re-authentication.
  • Google, GitHub, LinkedIn, and Microsoft (Azure AD) all support the use of refresh tokens in tandem with the Authorization Code Grant.

Final Word

The suitability of a grant type also depends on factors like the trustworthiness of the client, the sensitivity of the data, and the desired user experience. Always consider the specific needs and constraints of your scenario and adhere to the principle of least privilege, granting only the necessary access.

Existing web services such as Google, Reddit, Facebook, and Twitter may not support all grant types and will only provide support to grant types they feel are the most secure for their users.

When designing your own web services you can pick and choose which grant types you want to support.

Leave a Reply

%d bloggers like this: