JSON Web Token (JWT)

Securely transmit authentication and authorization data between systems using digitally signed tokens.

Last Updated date: July 2026

A JSON Web Token (JWT) is a compact, cryptographically signed token used to securely transmit identity claims between two parties, typically a client application and a server. It is the dominant standard for stateless authentication in modern APIs, microservices, and Single Sign-On (SSO) systems.

Quick Summary
Field	Detail
Full form	JSON Web Token
Category	Authentication & Authorization
Related to	IAM, OAuth 2.0, OIDC, SSO, Zero Trust
Primary use	Stateless user authentication in APIs and web apps
Key benefit	Verifies user identity without server-side session storage

Why JWT Matters for Identity Security

Session-based authentication requires servers to store and look up session data on every request, a bottleneck that breaks at scale. JWT eliminates that dependency.

When a user authenticates, the server issues a signed token. Every subsequent request carries that token. The server validates the signature and extracts claims directly, no database query, no central session store.

For organizations running distributed systems, microservices, or multi-application environments, this matters significantly. A single JWT issued by an identity provider can be trusted and consumed across dozens of services. That's the foundation of modern SSO and Zero Trust access models.

How JWT Authentication Works

User authenticates: Submits credentials (username/password, MFA, etc.) to the identity provider or application server.
Server issues a JWT: After verifying credentials, the server signs a token containing the user's identity claims and an expiration time.
Client stores the token: Typically in an HttpOnly cookie (preferred) or in-memory storage.
Client sends JWT with every request: In the Authorization: Bearer <token> HTTP header.
Server validates the signature: Checks the token's signature against the expected key. If valid, the server trusts the claims inside.
Access is granted or denied: Based on the claims (user role, permissions, expiry) extracted from the token.

No session lookup. No shared state between services. The token is self-contained proof of authentication.

The Three Parts of a JWT

A JWT is a string with three Base64URL-encoded segments separated by dots: header.payload.signature

Header Declares the token type (JWT) and the signing algorithm, for example, HS256 (HMAC with SHA-256) or RS256 (RSA with SHA-256).

{ "alg": "RS256", "typ": "JWT" }

Payload contains "claims", structured statements about the user and the token itself. Standard claims include sub (subject/user ID), exp (expiration time), iat (issued at), and custom claims like role or permissions.

{ "sub": "user_9821", "role": "admin", "exp": 1775000000 }

Signature: The cryptographic proof that the token hasn't been altered. Computed by signing the encoded header and payload using a secret key (HMAC) or a private key (RSA/ECDSA). A server can verify the token by re-computing the signature; no database call needed.

Note: The payload is Base64URL-encoded, not encrypted. Anyone who intercepts the token can read the claims. Never store passwords, PII, or sensitive data in a JWT payload.

JWT in Identity Governance and Access Control

JWTs integrate directly into identity governance workflows:

Role-based access control (RBAC): Role claims embedded in the token let downstream services enforce permissions without querying a directory on every request.
Least privilege enforcement: Token scopes and claims can limit access to specific resources, aligning with least privilege principles.
Audit and compliance: The iat, exp, and sub claims create a built-in audit trail of when access was granted and to whom.
Federated identity: An identity management framework (IAM) or identity provider issues tokens that multiple applications accept, enabling seamless SSO across enterprise systems.

Key Security Benefits

Tamper-evident: Any change to the payload invalidates the signature, making token forgery detectable
Stateless: Servers verify claims locally without shared session infrastructure
Scoped and time-limited: exp claims enforce automatic expiry; scopes limit what the token can access
Cross-service trust: Tokens issued by one identity governance platform can be validated by any service that trusts the issuer

Industry Use Cases

Financial services: Banks and fintech platforms use JWTs to authenticate API calls between front-end apps and core banking services, enforcing role-based permissions and logging every access event for SOX and PCI DSS compliance.

Healthcare: Patient portals and EHR integrations issue short-lived JWTs to control which providers can query which records, supporting HIPAA minimum-necessary access requirements.

SaaS and cloud-native platforms: Multi-tenant SaaS products embed tenant ID and user role in JWT claims, allowing a single access management solution to serve thousands of customers with isolated permission boundaries.

Enterprise IAM: Identity teams use JWTs within OIDC/OAuth 2.0 flows to federate authentication across cloud applications, VPNs, and on-premises systems, replacing legacy session cookies with a portable, Zero Trust-compatible credential.

JWT vs. Session-Based Authentication

	JWT	Session-Based
State location	Client-side (in token)	Server-side (in session store)
Scalability	High — no shared state needed	Limited — all servers need access to session store
Token revocation	Hard — requires token blocklist or short expiry	Easy — delete the session record
Cross-domain SSO	Native	Requires additional infrastructure
Performance	Fast — signature verified locally	Slower — requires session lookup

Bottom line: JWTs are better for distributed systems and APIs where scalability matters. Session-based auth is better when instant revocation is a hard requirement.

Implementation: Getting JWT Right

Poor JWT implementation is a leading source of authentication vulnerabilities. Follow these steps to deploy securely:

Use asymmetric algorithms: (RS256, ES256) for tokens consumed by multiple services. Reserve symmetric keys (HS256) for single-service scenarios where the key never leaves the issuer.
Set short expiry times: Access tokens should expire in 15–60 minutes. Use refresh tokens (stored server-side or in secure HttpOnly cookies) to reissue access tokens without re-authentication.
Validate on every request: Check the signature, the exp claim, the iss (issuer), and the aud (audience). Reject tokens that fail any check.
Never trust the alg header from user input: Enforce the expected algorithm server-side. Accepting "alg": "none" is a critical vulnerability that removes all signature verification.
Store tokens securely: HttpOnly, Secure cookies protect against XSS. Avoid localStorage for tokens with sensitive claims.
Implement a token blocklist: For high-privilege actions (admin operations, payment flows), maintain a short-lived revocation list to handle logout and compromised token scenarios.

JWT Security Risks to Know

JWT security is only as strong as its implementation. Common attack vectors include:

Algorithm confusion attacks: Switching the algorithm from RS256 to HS256 using the public key as the HMAC secret, allowing an attacker to forge valid tokens. Always enforce the algorithm server-side.
Weak signing keys: Short or guessable HMAC secrets can be brute-forced offline. Use cryptographically random keys of at least 256 bits.
Token theft via XSS: Tokens stored in localStorage are accessible to any JavaScript running on the page; a single XSS vulnerability exposes all tokens. Use HttpOnly cookies.
No expiry or long-lived tokens: Tokens without exp claims never expire. Stolen tokens remain valid indefinitely. Always set expiration and enforce it.
Sensitive data in payload: The payload is readable by anyone who holds the token. Treat it as a public-facing data structure.

Frequently Asked Questions

JWT stands for JSON Web Token. It is an open standard (RFC 7519) for transmitting claims between parties as a JSON object, cryptographically signed to ensure integrity.

By default, no. A standard JWT is signed, not encrypted. The payload is Base64URL-encoded and readable by anyone who holds the token. For encrypted tokens, the JWE (JSON Web Encryption) standard adds a confidentiality layer, but most applications use signed JWTs only.

OAuth 2.0 is an authorization framework that defines *how* tokens are issued and used. JWT is a token *format* commonly used by OAuth. You can have OAuth without JWT (using opaque tokens), but JWT within an OAuth flow is the most common pattern in modern identity systems.

Avoid JWTs when instant revocation is critical without a token blocklist, for example, high-security admin sessions where compromised credentials must be invalidated in real time. Session-based auth or short-lived JWTs with server-side blocklists are better choices in those cases.

Yes. JWTs carry claims, including roles, scopes, and permissions, that downstream services use to make authorization decisions. This is how role-based access control (RBAC) and attribute-based models work in distributed systems: the identity governance platform embeds the user's permissions into the token at issuance.

An expired JWT is rejected by the validating server. The client must request a new access token, typically using a refresh token stored in a secure HttpOnly cookie. The identity management framework handles re-issuance without requiring the user to log in again.