Summary of "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.

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.

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).

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.

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.

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.

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.

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.