OAuth 2.0 Grant Types | Authorization Code, Client Credentials, JWT & More

High-level summary

Core idea: OAuth 2.0 is delegation — letting an app act on your behalf without sharing your primary credentials.

This is a short tutorial explaining the main OAuth 2.0 grant types (flows), when to use each, and which ones to avoid.

Main flows explained

Authorization Code Flow

• What it is: Best practice for user-based apps with a backend server.
• How it works: The browser redirects the user to the identity provider (e.g., Google). The provider returns a one-time authorization code to the browser, and the app backend exchanges that code (privately) for an access token. The token is never exposed to the public-facing client.
• When to use: Classic web apps where a server can keep secrets.

Authorization Code + PKCE (Proof Key for Code Exchange)

• What it is: PKCE (often pronounced “pixie”) is a security extension to the authorization code flow for public clients that cannot keep a secret (mobile apps, single‑page apps).
• How it works: The client generates a code verifier (a secret) and a derived code challenge that is sent with the initial request. To exchange the authorization code for a token, the client must present the verifier, proving it started the flow and preventing interception/replay.
• When to use: Recommended standard for modern mobile apps and SPAs (public clients).

Client Credentials Flow

• What it is: For machine-to-machine / server-to-server communication (no user involved).
• How it works: The application authenticates using client_id + client_secret (like a username/password) and receives access tokens for service access (for example, a backend calling a shipping API).
• When to use: Simple server-to-server use cases, but vulnerable if credentials are stolen.

JWT (JWT Bearer) Flow

• What it is: A stronger machine-to-machine option using signed JWT assertions.
• How it works: The client presents a signed JWT (signed with a private key) instead of sending a shared secret. The receiver validates the signature with the public key. The private key is never transmitted.
• When to use: Preferred over client credentials for higher security in server-to-server authentication; signatures are harder to forge and theft of a server-side secret is less likely.

Flows to avoid

• Resource Owner Password Credentials (password flow)
  • The app asks the user for their actual identity-provider password. Strongly discouraged because it exposes user credentials to third-party apps.
• Implicit Flow
  • An early browser-only approach that returned access tokens directly in the browser/URL. Vulnerable to token leakage (exposed in URLs, browser history, intermediaries). It has been supplanted by Authorization Code + PKCE.

Quick cheat sheet (recommended choices)

• Classic server-rendered web app with backend: Authorization Code flow.
• Mobile apps / Single-page apps (public clients): Authorization Code with PKCE.
• Server-to-server: Client Credentials or JWT Bearer (JWT preferred for stronger security).
• Avoid: Password flow and Implicit flow for new apps.

Security takeaways

• Prefer flows that keep high-value tokens and secrets off public clients and out of URLs.
• Use PKCE for public clients that cannot store secrets.
• Prefer signed assertions (JWT) for stronger server authentication over static client secrets.

Speaker / sources

• Unnamed video narrator/host explaining OAuth 2.0 concepts; references identity providers like Google and the OAuth 2.0 model/spec implicitly.