OAuth 2.0 and Authorization Flows Cheat Sheet

Updated 2026-05-28

Next Topic: ORM and Database Abstraction Tools Cheat Sheet

🧠Study flashcards on this topic112 cards · spaced repetition→

OAuth 2.0 is an industry-standard authorization protocol that enables applications to obtain limited access to user resources without exposing credentials, forming the foundation for secure delegated access across the modern web. It separates authentication from authorization, allowing resource owners to grant third-party applications specific permissions through structured flows while maintaining control over their data. The protocol's flexibility supports diverse client types—from high-security server applications to browser-based SPAs and native mobile apps—while its extension ecosystem (PKCE, DPoP, PAR, mTLS, CIBA) addresses evolving security threats and deployment scenarios. Understanding OAuth 2.0's flows, token types, and security parameters is essential for building secure APIs, implementing single sign-on, protecting user data in distributed systems, and securing AI agent workflows against an expanding set of threats codified in RFC 9700 (Security BCP, January 2025).

What This Cheat Sheet Covers

This topic spans 19 focused tables and 167 indexed concepts, 112 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Core Authorization FlowsTable 2: PKCE Security ParametersTable 3: Token Types and PropertiesTable 4: OAuth 2.0 Scopes and PermissionsTable 5: Token Management OperationsTable 6: Client Authentication MethodsTable 7: OAuth 2.0 EndpointsTable 8: Authorization Request ParametersTable 9: OAuth 2.0 Client TypesTable 10: OpenID Connect IntegrationTable 11: Advanced OAuth Protocol ExtensionsTable 12: OAuth 2.0 Security Best PracticesTable 13: OAuth 2.0 Error CodesTable 14: Identity Providers and PlatformsTable 15: SSO Implementation PatternsTable 16: OAuth 2.1 Changes and ImprovementsTable 17: Dynamic Client RegistrationTable 18: FAPI 2.0 Financial-Grade Security ProfileTable 19: OAuth for AI Agents and MCP

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Core Authorization Flows

Each OAuth 2.0 grant type is designed for a specific use case; choosing the wrong one introduces avoidable security risks. The Authorization Code + PKCE flow is now the universal default for all user-facing clients, with Client Credentials handling machine-to-machine access—every other flow is either specialized or deprecated.

Flow	Example	Description
Authorization Code Flow with PKCE	`GET /authorize?response_type=code` `&code_challenge=E9Melhoa...` `&code_challenge_method=S256`	• Most secure flow for web, mobile, and SPA clients • PKCE mandatory in OAuth 2.1 for all client types • exchanges authorization code for tokens at server • protects against code interception attacks using dynamically generated code verifier/challenge pair.
Client Credentials Flow	`POST /token` `grant_type=client_credentials` `&client_id=xyz&client_secret=abc`	• Machine-to-machine (M2M) authentication without user interaction • service accounts exchange client ID/secret directly for access token • ideal for backend microservices, APIs, scheduled jobs, and server-to-server integration.
Refresh Token Flow	`POST /token` `grant_type=refresh_token` `&refresh_token=tGzv3J...`	• Exchanges long-lived refresh token for new short-lived access token without re-authentication • rotation recommended: issue new refresh token on each use and invalidate old one to limit breach impact.
Device Authorization Flow	`POST /device_authorization` `→ user_code: WDJB-MJHT` `→ verification_uri: /device`	• Designed for input-constrained devices (smart TVs, IoT, CLI tools) • user completes authorization on separate device with full browser • device polls token endpoint using device_code until user approves or request expires.
JWT Bearer Grant	`POST /token` `grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer` `&assertion=eyJhbGci...`	• Uses signed JWT as authorization grant for trust-based scenarios • enables cross-domain authentication and service-to-service delegation • JWT assertion replaces traditional client secret authentication.
Token Exchange	`POST /token` `grant_type=urn:ietf:params:oauth:grant-type:token-exchange` `&subject_token=...`	• Exchanges one token for another with different audience, scope, or format • supports impersonation and delegation scenarios • enables on-behalf-of flows where service acts on user's authority to call downstream APIs.
CIBA (Client-Initiated Backchannel Authentication)	`POST /bc-authorize` `login_hint=+1-555-...` `binding_message=A3B7`	• Decoupled flow: consumption device initiates auth, user authenticates on separate authentication device (phone) • three delivery modes: poll, ping, push • ideal for call centers, kiosks, POS, and AI agent human-in-the-loop scenarios.
Implicit Flow (deprecated)	`GET /authorize?response_type=token` `→ access_token in URL fragment`	• Removed in OAuth 2.1 • returned tokens directly in browser URL without server exchange • tokens exposed in browser history, logs, and Referer headers • replaced by Authorization Code + PKCE for all public clients.
Resource Owner Password Credentials (ROPC, legacy)	`POST /token` `grant_type=password` `&username=user&password=pass`	• Removed in OAuth 2.1; app collects user credentials directly • high security risk as credentials exposed to client; incompatible with MFA • use only for migration scenarios away from legacy systems.

Table 2: PKCE Security Parameters

PKCE (Proof Key for Code Exchange, RFC 7636) is the single most impactful security addition to the Authorization Code flow — it prevents authorization code interception by binding the token request to a secret known only to the initiating client. OAuth 2.1 mandates PKCE for all clients, not just public ones.

Parameter	Example	Description
code_verifier	`code_verifier=dBjftJeZ4CVP-mB...` (43–128 characters, cryptographically random)	• Cryptographically random string generated by client and kept secret • sent only in token request to prove possession • must contain only `A-Z`, `a-z`, `0-9`, `-`, `.`, `_`, `~` characters; minimum 43 chars entropy.

The rest of this section is part of the full cheat sheet

Table 3: Token Types and Properties

OAuth 2.0 tokens come in several forms, each with a distinct purpose and lifetime. Understanding the difference between access tokens, ID tokens, and refresh tokens — and choosing between opaque and JWT formats — determines both security posture and API performance.

Type	Example	Description
Access Token	`Authorization: Bearer eyJhbGci...`	• Credential used to access protected resources • typically short-lived (minutes to hours) • can be opaque string or self-contained JWT • contains scopes defining permissions; validated by resource server.

The rest of this section is part of the full cheat sheet

Table 4: OAuth 2.0 Scopes and Permissions

Scopes are the primary mechanism for expressing and enforcing granular permissions in OAuth 2.0. Well-designed scope structures balance API usability with least-privilege security; the Rich Authorization Requests extension (RFC 9396) goes further by encoding structured authorization data beyond simple strings.

Concept	Example	Description
Scope	`scope=read:profile write:posts admin`	• Space-delimited strings defining granular permissions • requested by client, approved by user, embedded in token • enforced by resource server to authorize each API operation.

The rest of this section is part of the full cheat sheet

Table 1: Core Authorization Flows

Flow	Example	Description
Authorization Code Flow with PKCE	`GET /authorize?response_type=code` `&code_challenge=E9Melhoa...` `&code_challenge_method=S256`	• Most secure flow for web, mobile, and SPA clients • PKCE mandatory in OAuth 2.1 for all client types • exchanges authorization code for tokens at server • protects against code interception attacks using dynamically generated code verifier/challenge pair.
Client Credentials Flow	`POST /token` `grant_type=client_credentials` `&client_id=xyz&client_secret=abc`	• Machine-to-machine (M2M) authentication without user interaction • service accounts exchange client ID/secret directly for access token • ideal for backend microservices, APIs, scheduled jobs, and server-to-server integration.
Refresh Token Flow	`POST /token` `grant_type=refresh_token` `&refresh_token=tGzv3J...`	• Exchanges long-lived refresh token for new short-lived access token without re-authentication • rotation recommended: issue new refresh token on each use and invalidate old one to limit breach impact.
Device Authorization Flow	`POST /device_authorization` `→ user_code: WDJB-MJHT` `→ verification_uri: /device`	• Designed for input-constrained devices (smart TVs, IoT, CLI tools) • user completes authorization on separate device with full browser • device polls token endpoint using device_code until user approves or request expires.
JWT Bearer Grant	`POST /token` `grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer` `&assertion=eyJhbGci...`	• Uses signed JWT as authorization grant for trust-based scenarios • enables cross-domain authentication and service-to-service delegation • JWT assertion replaces traditional client secret authentication.
Token Exchange	`POST /token` `grant_type=urn:ietf:params:oauth:grant-type:token-exchange` `&subject_token=...`	• Exchanges one token for another with different audience, scope, or format • supports impersonation and delegation scenarios • enables on-behalf-of flows where service acts on user's authority to call downstream APIs.
CIBA (Client-Initiated Backchannel Authentication)	`POST /bc-authorize` `login_hint=+1-555-...` `binding_message=A3B7`	• Decoupled flow: consumption device initiates auth, user authenticates on separate authentication device (phone) • three delivery modes: poll, ping, push • ideal for call centers, kiosks, POS, and AI agent human-in-the-loop scenarios.
Implicit Flow (deprecated)	`GET /authorize?response_type=token` `→ access_token in URL fragment`	• Removed in OAuth 2.1 • returned tokens directly in browser URL without server exchange • tokens exposed in browser history, logs, and Referer headers • replaced by Authorization Code + PKCE for all public clients.
Resource Owner Password Credentials (ROPC, legacy)	`POST /token` `grant_type=password` `&username=user&password=pass`	• Removed in OAuth 2.1; app collects user credentials directly • high security risk as credentials exposed to client; incompatible with MFA • use only for migration scenarios away from legacy systems.

Table 2: PKCE Security Parameters

Parameter	Example	Description
code_verifier	`code_verifier=dBjftJeZ4CVP-mB...` (43–128 characters, cryptographically random)	• Cryptographically random string generated by client and kept secret • sent only in token request to prove possession • must contain only `A-Z`, `a-z`, `0-9`, `-`, `.`, `_`, `~` characters; minimum 43 chars entropy.

Table 3: Token Types and Properties

Type	Example	Description
Access Token	`Authorization: Bearer eyJhbGci...`	• Credential used to access protected resources • typically short-lived (minutes to hours) • can be opaque string or self-contained JWT • contains scopes defining permissions; validated by resource server.

Table 4: OAuth 2.0 Scopes and Permissions

Concept	Example	Description
Scope	`scope=read:profile write:posts admin`	• Space-delimited strings defining granular permissions • requested by client, approved by user, embedded in token • enforced by resource server to authorize each API operation.