An introduction to OAuth 2.0

4-minute read
Paul Reardon
Technical • Security
Authorisation

OAuth 2.0 is an authorisation framework that allows applications to securely access resources on behalf of a user without requiring the user to share their credentials directly with the application. It achieves this by obtaining limited access to a user’s account on a service (like Google, Facebook, etc.) and authorising third-party applications to act on that user’s behalf.

Key Roles in OAuth 2.0

OAuth 2 is still a tri-party trust (trust between the Client, Server and Authority) below shows the 4 key roles.

OAuth Overview

  • Resource Owner: The user (Natural person) who owns the protected resource (e.g. their bank account at a bank or medical records at a hospital)
  • Client: The application seeking access to the protected resource on behalf of the resource owner.
  • Resource Server: The server hosting the protected resource.
  • Authorisation Server: The server that authenticates the resource owner and issues access tokens to the client after obtaining proper authorisation.

Grant Types

OAuth 2.0 has a couple of different Grant Types or Flows that are used to obtain authorisation.

Main Grant Types

  1. Authorisation Code Flow:
    • Use Cases: Primarily used by web applications and native apps (Mobile or Desktop) where the source code is confidential. Considered the most secure flow for many scenarios.
    • Description: The client redirects the user to the authorisation server for login and consent. After authorisation, the server sends an authorisation code to the client. The client then exchanges this code for an access token and/or refresh token. This grant type has taken favour for public clients over the Implicit flow after some security concerns were discovered.
    • For more information on Authorisation Code flow with PKCE please read my PKCE article here
  2. Client Credentials Flow:
    • Use Cases: Machine-to-machine communication and server-to-server authentication where user authorisation is not applicable.
    • Description: The client authenticates itself with its client ID and secret and requests an access token directly from the authorisation server without user involvement.
  3. Device Code Flow:
    • Use Cases: Enabling authorisation on devices that cannot directly interact with the authorisation server.
    • Description: Designed for input-constrained devices (like smart TVs, CLI tools). The device displays a code, and the user goes to a different device (like a computer or smartphone) to enter that code and authorise the application.
  4. Implicit Flow (Legacy):
    • Use Cases: Historically used for single-page applications (SPAs) but has largely been replaced by the authorisation code flow with PKCE due to security concerns.
    • Description: Similar to the authorisation code flow, but the access token is sent directly to the client in the initial redirect, bypassing the need for a code exchange.
  5. Resource Owner Password Credentials Flow (Legacy):
    • Use Cases: Only recommended for trusted first-party clients or legacy applications where other flows are not feasible due to security concerns.
    • Description: The user provides their username and password directly to the client, which then uses these credentials to obtain an access token from the authorisation server.

Lesser used Grant Types

  1. Refresh Token Grant:
    • Use Cases: Used to obtain a new access token when the current one expires, without requiring the user to re-authenticate.
    • Description: The client sends a refresh token (obtained during the initial authorisation) to the authorisation server, which verifies its validity and issues a new access token in return.
    • Security Note: Refresh tokens should be treated as highly sensitive and stored securely, as they can be used to obtain new access tokens without user interaction.
  2. Assertion Grant:
    • Use Cases: Designed for situations where the client can assert its identity to the authorisation server using a trusted credential (e.g. a SAML assertion, a JSON Web Token (JWT)). Useful in scenarios where a separate identity provider or authentication mechanism is already in place.
    • Description: The client presents the assertion to the authorisation server, which validates it and issues an access token if the assertion is deemed valid.
  3. Token Exchange Grant (RFC 8693):
    • Use Cases: Enables the exchange of one type of token for another (e.g. exchanging an access token from one service for a different access token from another service). Useful in federated identity scenarios, where a user’s identity is managed across multiple services or domains.
    • Description: The client sends a token and some metadata (e.g. the desired target audience or scope) to the authorisation server, which validates the token and issues a new token if the request is valid.
    • For more information on Token Exchange flow with PKCE please read my token exchange article here
  4. User-Managed Access (UMA) Grant (RFC 9125):
    • Use Cases: Extends OAuth 2.0 to give users more granular control over their data and who can access it. Useful in privacy-focused applications and scenarios where users need fine-grained control over their data sharing.
    • Description: Users can create and manage authorisation policies (e.g. “Allow my doctor to access my health records”) using a central authorisation server. Applications request access to protected resources, and the authorisation server enforces the user’s policies.

Summary

OAuth 2.0 remains the cornerstone of modern authorisation, offering a flexible framework with a variety of grant types to suit diverse use cases. By understanding these grant types and their security implications, developers can choose the most appropriate flow for their applications, ensuring secure and user-friendly access to protected resources.