JSON Web Token (JWT)
A compact, digitally signed token format (RFC 7519) used for securely transmitting information between parties.
What is JSON Web Token (JWT)?
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact way to securely transmit information between parties as a JSON object. JWTs are digitally signed using a secret (HMAC) or a public/private key pair (RSA, ECDSA).
In CIAM architectures, JWTs are the primary token format for:
- ID Tokens (OpenID Connect) - contain user identity claims
- Access Tokens (OAuth 2.0) - grant access to resources
- Custom tokens - internal service-to-service authentication
JWT Structure (3 parts separated by dots):
- Header: Specifies algorithm (HS256, RS256) and token type (JWT)
- Payload: Contains claims (iss, sub, exp, custom claims)
- Signature: Verifies the token wasn't tampered with
Key CIAM consideration for engineers: Always validate the signature, expiration (exp), issuer (iss), and audience (aud) when receiving a JWT. Never accept unsigned or expired tokens.
Analogy
Think of a JWT like a sealed envelope with a tamper-proof sticker. Anyone can read it, but if someone tries to change the contents, the seal breaks and you know it's been tampered with.
Types and Use Cases
Types of JWTs in CIAM:
- ID Token (OpenID Connect): Contains user identity claims (sub, email, name). Audience is the client application.
- Access Token (OAuth 2.0): Grants access to protected resources (APIs). May be opaque or JWT format.
- Refresh Token: Long-lived token used to obtain new access tokens without re-authentication.
- Custom JWTs: Internal service authentication, API gateway tokens, microservices auth.
CIAM Use Cases:
- Single Sign-On (SSO): OIDC ID token proves user identity across applications
- API Security: OAuth access token (JWT) grants scoped access to user resources
- Microservices: Service-to-service auth using JWTs with private key signing (RS256)
- Mobile Apps: Store JWT in secure storage (Keychain/Keystore), not localStorage (XSS risk)
- B2B Federation: Trust JWTs signed by partner IdPs (Azure AD, Okta) via JWKS endpoint
How it Works
// JWT Structure (decoded)
{
"header": {
"alg": "RS256",
"typ": "JWT"
},
"payload": {
"iss": "https://loginradius.com",
"sub": "usr_8f3a2b1c9d",
"aud": "client_12345",
"exp": 1778058040,
"iat": 1778054440,
"email": "user@example.com",
"name": "John Doe"
},
"signature": "HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret)"
}
// Usage in API request
GET /api/user/profile
Authorization: Bearer eyJhbGciOiJSUzI1N...JSON Web Token (JWT) vs Opaque Tokens
JSON Web Token (JWT)
Opaque Tokens
JWT is self-contained (all claims inside)
Opaque tokens are reference tokens (need introspection/lookup)
JWT can be validated without database lookup (stateless)
Opaque requires introspection endpoint call (stateful)
JWT can be inspected by client (debugging, has the user info)
Opaque hides all claims from client (more secure from XSS)
JWT has size limit (grows with claims)
Opaque is just a random string (short, efficient)
JWT is better for stateless APIs and microservices
Opaque is better for revocation (delete from DB immediately)
Best Practices for JSON Web Token (JWT)
CIAM JWT Security Best Practices:
- Always validate signature, expiration, issuer, and audience on the server - never trust client-side validation
- Use RS256 (asymmetric) over HS256 (symmetric) for multi-service environments - allows public key verification without sharing secrets
- Don't store sensitive data in JWT payload - it's Base64 encoded (not encrypted), anyone can decode it
- Set short expiration times (5-15 minutes for access tokens); use refresh tokens for long-lived sessions
- Use HTTPS only - JWTs in Authorization header can be intercepted on HTTP; always use TLS in transit
- Implement token revocation - JWTs can't be revoked by default (stateless); use blocklist/denylist for compromised tokens
How LoginRadius Powers JSON Web Token (JWT)
LoginRadius CIAM platform provides comprehensive JWT support for modern identity architectures, issuing and validating JWTs across all authentication flows.
JWT Issuance:
- ID Tokens (OpenID Connect): RS256-signed JWTs containing user identity claims (sub, email, name, custom attributes)
- Access Tokens (OAuth 2.0): JWT or opaque format, configurable via LoginRadius dashboard
- Custom claims: Add tenant_id, user roles, permissions, or any custom attributes to JWT payload
- JWKS endpoint: LoginRadius publishes public keys at
/.well-known/jwks.jsonfor token validation
JWT Validation & Security:
- Built-in validation: LoginRadius APIs automatically validate JWT signature, expiration, issuer, and audience
- Introspection endpoint: For opaque tokens, LoginRadius provides RFC 7662 compliant introspection
- Token lifecycle: Configurable expiration (5 min - 24 hours), automatic refresh token rotation
- Revocation support: Logout, session termination, and compromised token blocklisting
Developer Integration:
- SDK support: JavaScript, React, Android, iOS, and server-side SDKs handle JWT generation and validation
- Quick Start: Mobile apps receive JWT after login, include in API calls:
Authorization: Bearer <jwt> - Debugging: LoginRadius dashboard shows issued tokens, validation logs, and failure reasons
- Enterprise: Support for custom signing keys, key rotation, and JWKS publishing for partner federation
FAQs
- JWT (JSON Web Token) is self-contained - contains all claims (sub, email, permissions) inside the token; can be validated without database lookup
- Opaque Token is a reference token - just a random string; server must call introspection endpoint to validate and get claims
- JWT pros: Stateless, scalable, no DB lookup needed, client can inspect claims (debugging)
- JWT cons: Can't revoke easily (stateless), size grows with claims, exposed if XSS occurs
- Opaque pros: Can revoke immediately (delete from DB), hides claims from client (more secure), short and efficient
- CIAM recommendation: Use JWT for access tokens (stateless APIs), opaque for refresh tokens (revocable)
- Step 1: Extract JWT from
Authorization: Bearer <token>header - Step 2: Verify signature using LoginRadius JWKS endpoint (
/.well-known/jwks.json) - fetch public key matchingkidheader - Step 3: Verify standard claims -
iss(must be LoginRadius),aud(must be your client_id),exp(not expired),iat(not in future) - Step 4: Verify custom claims if needed (user roles, permissions, tenant_id)
- Never skip validation - expired or invalid JWTs must be rejected; always use established libraries (not manual parsing)
- JWT is better for APIs and mobile apps - stateless, scalable, works across domains (CORS), perfect for microservices
- Sessions (cookies) are better for web apps - automatically handled by browser, CSRF protection possible, easier to revoke
- Hybrid approach (recommended): Use session cookie for web frontend (UX), JWT for API calls (scalability)
- LoginRadius supports both: Session-based auth for traditional web apps, JWT for SPAs, mobile apps, and API access
- Security note: If using JWT in browser, store in HttpOnly cookie (not localStorage) to prevent XSS theft