OAuth 2.0 Grant Types

Confidential clients (server-side web apps) that can securely store a client secret

The Authorization Code grant is the most secure OAuth 2.0 flow. The user authenticates with the authorization server, which returns a short-lived code to the redirect URI. The server (not the browser) exchanges the code for tokens using the client secret. The access token is never exposed to the browser. Use for server-side web applications.

Public clients: single-page apps (SPA), mobile apps, CLI tools that cannot securely store a client secret

PKCE (Proof Key for Code Exchange, RFC 7636) extends Authorization Code for public clients. The client generates a cryptographically random code_verifier, computes code_challenge = BASE64URL(SHA256(verifier)), and sends the challenge in the authorization request. At token exchange, the verifier is sent instead of a client secret – proving the same client initiated both steps.

Confidential clients acting on their own behalf (no user involved) – machine-to-machine (M2M)

The Client Credentials grant issues tokens to applications acting on their own behalf, not on behalf of a user. A service authenticates with its client_id and client_secret to get an access token. No user authorization UI involved. Standard for microservice-to-microservice API calls, batch jobs, background workers, and CI/CD pipelines calling APIs.

Input-constrained devices: Smart TVs, game consoles, CLI tools, IoT devices that cannot open a browser

The Device Authorization Grant (RFC 8628) lets devices with no browser or limited input (TV, CLI, IoT sensor) authorize by displaying a short code and URL. The user enters the code on another device (phone/computer). The device polls the authorization server until the user completes authorization. Used by YouTube on TV, Spotify on TV, GitHub CLI, AWS CLI.