API Authentication Cheat Sheet

Updated 2026-04-29

Next Topic: API Gateway Configuration and Patterns Cheat Sheet

🧠Study flashcards on this topic138 cards · spaced repetition→

API authentication is the process of verifying the identity of clients making requests to an API, forming the foundation of API security in modern distributed systems. Unlike traditional web authentication that relies on session cookies, API authentication must work across stateless HTTP requests, supporting diverse clients from web browsers to mobile apps and server-to-server integrations. The challenge lies in balancing security with developer experience—while robust authentication prevents unauthorized access and data breaches, overly complex implementations create friction that slows development and adoption. In 2026, the field is evolving rapidly: OAuth 2.1 consolidates best practices with mandatory PKCE and sender-constrained tokens (DPoP), passkeys/WebAuthn are accelerating mainstream adoption, and AI agents communicating via MCP are driving delegated authorization at scale.

What This Cheat Sheet Covers

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

Table 1: Core Authentication MethodsTable 2: OAuth 2.0 Grant TypesTable 3: JWT Structure and ClaimsTable 4: JWT Signing AlgorithmsTable 5: Token Types and LifecycleTable 6: API Key Security PatternsTable 7: HTTP Authentication SchemesTable 8: Session and Cookie SecurityTable 9: OAuth Scopes and PermissionsTable 10: Authentication Best PracticesTable 11: Advanced Authentication PatternsTable 12: Cross-Origin and CORSTable 13: Security Headers for APIsTable 14: API Security TestingTable 15: Common Authentication PitfallsTable 16: GraphQL-Specific AuthenticationTable 17: Monitoring and Observability

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 Authentication Methods

Every API auth strategy is some variation on a few primitives—a static key, a bearer token, a delegated grant, or a certificate—and knowing which one fits your situation is half the battle. The entries here span the full spectrum from the dead-simple API key suited to server-to-server traffic, through the OAuth/OIDC family that dominates modern user-facing apps, to phishing-resistant passkeys and the heavyweight enterprise options. Most are listed roughly from "reach for this today" down to "you'll only meet this in legacy systems."

Method	Example	Description
API Key	`X-API-Key: sk_live_51H...`	• Static token identifying the calling application • simple but not tied to specific users, best for server-to-server calls where client identity matters more than user identity.
Bearer Token	`Authorization: Bearer eyJhbGc...`	• Generic token authentication scheme (RFC 6750) • the token itself carries authentication proof and must be sent with every request — stolen tokens grant full access unless sender-constrained.
OAuth 2.0	`grant_type=authorization_code&` `code=xyz&redirect_uri=...`	• Delegation protocol allowing third-party apps to access user resources without sharing passwords • returns access tokens for API calls.
OpenID Connect (OIDC)	`scope=openid profile email`	• Authentication layer built on OAuth 2.0 • returns an ID token (JWT) containing user identity alongside access tokens for resource access.
OAuth 2.1	Uses Authorization Code + PKCE	• Modern OAuth profile mandating PKCE for all flows, removing implicit and password grants • the recommended standard for new implementations.
JWT (JSON Web Token)	`eyJhbGciOiJIUzI1NiJ9.eyJzdWI...`	• Self-contained token encoding claims as JSON, verifiable via signature • enables stateless authentication without database lookups per request.
mTLS (Mutual TLS)	Client presents certificate in TLS handshake	• Both client and server authenticate via X.509 certificates • strongest authentication for service-to-service, though complex certificate management is required.
HMAC Signature	`Authorization: HMAC-SHA256` `Credential=KEY, SignedHeaders=...,` `Signature=abc123...`	• Request signed using shared secret (e.g., AWS Signature v4) • proves request integrity and authenticity without sending the secret itself.
WebAuthn / FIDO2	Passkey stored in authenticator device	• Passwordless authentication using public-key cryptography and biometrics • phishing-resistant, device-bound credentials, growing mainstream adoption in 2026.
Session-Based	`Cookie: session_id=abc123; Secure;` `HttpOnly; SameSite=Strict`	• Server stores session state tied to a cookie ID • traditional for web apps but requires server-side storage and sticky sessions in distributed deployments.
HTTP Basic	`Authorization: Basic dXNlcjpwYXNz`	• Base64-encoded `username:password` sent in header • credentials sent with every request, requires HTTPS, rarely used in APIs today.
SAML 2.0	XML assertion with digital signature	• Enterprise SSO standard exchanging XML assertions between identity provider and service provider • heavy XML format, primarily for web-based enterprise SSO.
HTTP Digest	`Authorization: Digest username="user",` `realm="api", nonce="..."`	• Challenge-response mechanism hashing credentials with nonce • avoids plaintext passwords but MD5-based and largely obsolete in modern APIs.

Table 2: OAuth 2.0 Grant Types

A grant type is simply the path a client takes to obtain a token, and OAuth defines a different one for each kind of client—a server-side web app, a single-page app, a machine talking to another machine, or a TV with no keyboard. The two at the top, Authorization Code with PKCE and plain Authorization Code, are the workhorses you should default to; the two at the bottom are flagged deprecated because OAuth 2.1 removed them outright over token-leakage and credential-handling risks.

Grant	Example	Description
Authorization Code + PKCE	`code_challenge=...` `code_challenge_method=S256` Then: `code_verifier=...`	• Required for all public clients (SPAs, mobile) per OAuth 2.1 • prevents authorization code interception by binding the exchange to a cryptographic code verifier.

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

Table 3: JWT Structure and Claims

A JWT is just three base64 segments—header, payload, signature—joined by dots, and the payload carries a set of standard "claims" that every verifier should check. The first rows break down that anatomy; the rest cover the registered claims like iss, aud, and exp that pin down who issued the token, who it's for, and when it dies. Treat the payload as readable-by-anyone: it's signed, not encrypted, so never put secrets there.

Component	Example	Description
Header	`{"alg":"RS256","typ":"JWT","kid":"key-1"}`	• Contains token type and signing algorithm (HS256, RS256, ES256, EdDSA) • decoded by anyone but signature prevents tampering.

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

Table 4: JWT Signing Algorithms

The signing algorithm decides who can mint a valid token and who can only verify one—the single most consequential choice in a JWT setup. Asymmetric options (RS256, ES256, EdDSA, PS256) keep the private signing key on the auth server alone while every resource server verifies with the public key, which is what you want in any distributed system; the lone symmetric option, HS256, shares one secret with every verifier, so a single compromised service can forge tokens for all the others.

Algorithm	Example	Description
RS256	`{"alg":"RS256"}` — RSA 2048-bit private key signs, public key verifies	• Most widely deployed asymmetric algorithm • only the auth service holds the private key, any service verifies with the public key via JWKS • susceptible to Bleichenbacher attacks if library is misconfigured.

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

Table 1: Core Authentication Methods

Method	Example	Description
API Key	`X-API-Key: sk_live_51H...`	• Static token identifying the calling application • simple but not tied to specific users, best for server-to-server calls where client identity matters more than user identity.
Bearer Token	`Authorization: Bearer eyJhbGc...`	• Generic token authentication scheme (RFC 6750) • the token itself carries authentication proof and must be sent with every request — stolen tokens grant full access unless sender-constrained.
OAuth 2.0	`grant_type=authorization_code&` `code=xyz&redirect_uri=...`	• Delegation protocol allowing third-party apps to access user resources without sharing passwords • returns access tokens for API calls.
OpenID Connect (OIDC)	`scope=openid profile email`	• Authentication layer built on OAuth 2.0 • returns an ID token (JWT) containing user identity alongside access tokens for resource access.
OAuth 2.1	Uses Authorization Code + PKCE	• Modern OAuth profile mandating PKCE for all flows, removing implicit and password grants • the recommended standard for new implementations.
JWT (JSON Web Token)	`eyJhbGciOiJIUzI1NiJ9.eyJzdWI...`	• Self-contained token encoding claims as JSON, verifiable via signature • enables stateless authentication without database lookups per request.
mTLS (Mutual TLS)	Client presents certificate in TLS handshake	• Both client and server authenticate via X.509 certificates • strongest authentication for service-to-service, though complex certificate management is required.
HMAC Signature	`Authorization: HMAC-SHA256` `Credential=KEY, SignedHeaders=...,` `Signature=abc123...`	• Request signed using shared secret (e.g., AWS Signature v4) • proves request integrity and authenticity without sending the secret itself.
WebAuthn / FIDO2	Passkey stored in authenticator device	• Passwordless authentication using public-key cryptography and biometrics • phishing-resistant, device-bound credentials, growing mainstream adoption in 2026.
Session-Based	`Cookie: session_id=abc123; Secure;` `HttpOnly; SameSite=Strict`	• Server stores session state tied to a cookie ID • traditional for web apps but requires server-side storage and sticky sessions in distributed deployments.
HTTP Basic	`Authorization: Basic dXNlcjpwYXNz`	• Base64-encoded `username:password` sent in header • credentials sent with every request, requires HTTPS, rarely used in APIs today.
SAML 2.0	XML assertion with digital signature	• Enterprise SSO standard exchanging XML assertions between identity provider and service provider • heavy XML format, primarily for web-based enterprise SSO.
HTTP Digest	`Authorization: Digest username="user",` `realm="api", nonce="..."`	• Challenge-response mechanism hashing credentials with nonce • avoids plaintext passwords but MD5-based and largely obsolete in modern APIs.

Table 2: OAuth 2.0 Grant Types

Grant	Example	Description
Authorization Code + PKCE	`code_challenge=...` `code_challenge_method=S256` Then: `code_verifier=...`	• Required for all public clients (SPAs, mobile) per OAuth 2.1 • prevents authorization code interception by binding the exchange to a cryptographic code verifier.

Table 3: JWT Structure and Claims

Component	Example	Description
Header	`{"alg":"RS256","typ":"JWT","kid":"key-1"}`	• Contains token type and signing algorithm (HS256, RS256, ES256, EdDSA) • decoded by anyone but signature prevents tampering.

Table 4: JWT Signing Algorithms

Algorithm	Example	Description
RS256	`{"alg":"RS256"}` — RSA 2048-bit private key signs, public key verifies	• Most widely deployed asymmetric algorithm • only the auth service holds the private key, any service verifies with the public key via JWKS • susceptible to Bleichenbacher attacks if library is misconfigured.