JWT JSON Web Tokens Cheat Sheet

Updated 2026-05-16

Next Topic: Koa.js Node.js Framework Cheat Sheet

🧠Study flashcards on this topic101 cards · spaced repetition→

JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between parties as a compact, URL-safe JSON object. JWTs are widely used for stateless authentication in modern web applications, APIs, and microservices—eliminating the need for server-side session storage. Each token is self-contained (carrying claims about the user), signed to ensure integrity, and optionally encrypted for confidentiality. The key mental model: a JWT is not a session—it's a portable proof of identity that any service with the right key can verify independently, making it ideal for distributed systems but requiring careful handling to prevent token theft, replay attacks, and algorithm confusion exploits.

What This Cheat Sheet Covers

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

Table 1: Token Structure & EncodingTable 2: Signing AlgorithmsTable 3: Registered ClaimsTable 4: Header ParametersTable 5: Custom Claims & AuthorizationTable 6: Token Verification StepsTable 7: Token Storage LocationsTable 8: Access & Refresh Token PatternsTable 9: Revocation StrategiesTable 10: Security Vulnerabilities & AttacksTable 11: Libraries by LanguageTable 12: JWKS (JSON Web Key Set) EndpointsTable 13: JWT in Microservices & Distributed SystemsTable 14: OAuth 2.0 & OpenID Connect IntegrationTable 15: Advanced JWT Features & ExtensionsTable 16: Best Practices & Security GuidelinesTable 17: Testing & Debugging ToolsTable 18: Common Implementation Mistakes

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: Token Structure & Encoding

Every JWT is three Base64URL segments glued together by dots — header, payload, signature — and that anatomy is the foundation for everything else here. The header declares how the token is signed, the payload carries the claims, and the signature locks both against tampering. Crucially, Base64URL is encoding, not encryption, so anyone holding the token can read the first two parts.

Component	Example	Description
Header	`{"alg":"HS256", "typ":"JWT"}`	• JSON object specifying token type and signing algorithm • Base64URL-encoded to form first segment
Payload	`{"sub":"1234", "name":"Alice", "iat":1516239022}`	• JSON object containing claims (statements about an entity) • Base64URL-encoded as second segment
Signature	`HMACSHA256(base64(header) + "." + base64(payload), secret)`	• Cryptographic signature ensuring integrity • computed from encoded header + payload + secret/key
Complete JWT format	`eyJhbGc...header.eyJzdWI...payload.SflKxw...signature`	Three Base64URL-encoded segments separated by dots: `header.payload.signature`
Base64URL encoding	`eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9`	• URL-safe Base64 variant using `-` and `_` instead of `+` and `/` • padding optional.

Table 2: Signing Algorithms

The choice of signing algorithm is the single most consequential security decision you make with JWTs. Symmetric options like HS256 share one secret between issuer and verifier and run fast, while asymmetric families — RS256, ES256, PS256, EdDSA — let anyone verify with a public key while only the issuer holds the private one, which is what you want across services or in public clients. The deprecated none algorithm sits at the bottom as a reminder that unsigned tokens must always be rejected.

Algorithm	Example	Description
HS256	`{"alg": "HS256"}`	• HMAC with SHA-256 • symmetric (shared secret) • fast but requires all parties to trust the secret • performance ~tens of microseconds

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

Table 3: Registered Claims

These are the standardized claims defined directly in RFC 7519 — the shorthand three-letter keys (iss, sub, aud, exp, and friends) that every compliant library understands without configuration. They answer the core questions a verifier asks of any token: who issued it, who it's about, who it's for, and when it's valid.

Claim	Example	Description
iss (issuer)	`{"iss": "`	• Identifies the principal that issued the JWT • typically a URL • validators must verify it matches expected issuer

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

Table 4: Header Parameters

Header parameters live in that first segment and tell the verifier how to process the token before it even looks at the claims. The most important is alg, but several others — kid, jku, x5u — point the verifier at which key to use, and those are precisely the fields attackers love to manipulate, so anything that resolves to a key or a URL must be validated against a trusted list.

Parameter	Example	Description
alg (algorithm)	`{"alg": "RS256"}`	• Specifies cryptographic algorithm for signing or encryption • must be validated by recipient to prevent algorithm-confusion attacks

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

Table 1: Token Structure & Encoding

Component	Example	Description
Header	`{"alg":"HS256", "typ":"JWT"}`	• JSON object specifying token type and signing algorithm • Base64URL-encoded to form first segment
Payload	`{"sub":"1234", "name":"Alice", "iat":1516239022}`	• JSON object containing claims (statements about an entity) • Base64URL-encoded as second segment
Signature	`HMACSHA256(base64(header) + "." + base64(payload), secret)`	• Cryptographic signature ensuring integrity • computed from encoded header + payload + secret/key
Complete JWT format	`eyJhbGc...header.eyJzdWI...payload.SflKxw...signature`	Three Base64URL-encoded segments separated by dots: `header.payload.signature`
Base64URL encoding	`eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9`	• URL-safe Base64 variant using `-` and `_` instead of `+` and `/` • padding optional.

Table 2: Signing Algorithms

Algorithm	Example	Description
HS256	`{"alg": "HS256"}`	• HMAC with SHA-256 • symmetric (shared secret) • fast but requires all parties to trust the secret • performance ~tens of microseconds

Table 3: Registered Claims

Claim	Example	Description
iss (issuer)	`{"iss": "`	• Identifies the principal that issued the JWT • typically a URL • validators must verify it matches expected issuer

Table 4: Header Parameters

Parameter	Example	Description
alg (algorithm)	`{"alg": "RS256"}`	• Specifies cryptographic algorithm for signing or encryption • must be validated by recipient to prevent algorithm-confusion attacks

JWT (JSON Web Tokens) Cheat Sheet

Table 1: Token Structure & Encoding

Table 2: Signing Algorithms

Table 3: Registered Claims

Table 4: Header Parameters

JWT (JSON Web Tokens) Cheat Sheet

Table 1: Token Structure & Encoding

Table 2: Signing Algorithms

Table 3: Registered Claims

Table 4: Header Parameters