JWT Use Cases

JSON Web Tokens are used in a wide variety of applications and scenarios. Understanding these use cases helps you implement JWTs correctly and identify potential security issues.

1. Single Sign-On (SSO)

JWTs are commonly used in SSO systems to allow users to authenticate once and access multiple applications without re-entering credentials.

SSO Flow

// User logs in to Identity Provider
POST /auth/login
{
  "username": "user@example.com",
  "password": "password"
}

// Identity Provider issues JWT
{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "expires_in": 3600
}

// User accesses Service A with same token
GET /api/service-a/data
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

// User accesses Service B with same token
GET /api/service-b/data
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Benefits: Centralized authentication, reduced password fatigue, improved user experience across multiple services.

2. API Authentication

JWTs provide stateless authentication for REST APIs, eliminating the need for server-side session storage.

API Authentication

// Client authenticates
POST /api/auth/login
{
  "username": "api_user",
  "password": "api_key"
}

// Server responds with JWT
{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 3600
}

// Client uses token for API calls
GET /api/users
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

// Server validates token and responds
{
  "users": [...]
}

Benefits: Stateless, scalable, works across microservices, no session storage required.

3. Microservices Communication

JWTs enable secure service-to-service communication in microservices architectures without shared session stores.

Microservices Communication

// User authenticates with API Gateway
POST /gateway/auth
→ Issues JWT with user context

// API Gateway forwards request to User Service
GET /users/123
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
→ User Service validates token
→ Returns user data

// User Service calls Order Service
GET /orders?userId=123
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
→ Order Service validates same token
→ Returns orders

// All services can validate token independently
// No shared session store needed

Benefits: Decentralized validation, no shared state, each service can validate independently.

4. Mobile App Authentication

Mobile applications use JWTs for authentication, allowing offline token validation and reduced server load.

Mobile Authentication

// Mobile app login
POST /api/mobile/login
{
  "username": "user@example.com",
  "password": "password"
}

// Server issues JWT
{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "expires_in": 3600
}

// App stores token securely (Keychain/Keystore)
// App includes token in all API requests
GET /api/mobile/profile
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

// Token can be validated offline (if public key available)
// Reduces server load for validation

Benefits: Offline validation possible, reduced server load, secure storage in device keychain.

5. OAuth 2.0 / OpenID Connect

JWTs are the standard token format for OAuth 2.0 access tokens and OpenID Connect ID tokens.

OAuth 2.0 Flow

// OAuth 2.0 Authorization Code Flow
// 1. User authorizes application
GET /oauth/authorize?client_id=app&redirect_uri=...

// 2. User redirected with authorization code
GET /callback?code=abc123

// 3. Application exchanges code for tokens
POST /oauth/token
{
  "grant_type": "authorization_code",
  "code": "abc123",
  "client_id": "app",
  "client_secret": "secret"
}

// 4. Server responds with JWT
{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "id_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."  // OpenID Connect
}

// 5. Application uses access token
GET /api/userinfo
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Benefits: Standardized, interoperable, supports delegation, widely adopted.

6. Passwordless Authentication

JWTs can be used for passwordless authentication flows using magic links or one-time codes.

Passwordless Authentication

// User requests passwordless login
POST /auth/passwordless/request
{
  "email": "user@example.com"
}

// Server sends magic link with JWT
Email: https://app.com/auth/verify?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

// User clicks link
GET /auth/verify?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

// Server validates token and issues session JWT
{
  "session_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "expires_in": 86400
}

// Alternative: One-time code
POST /auth/passwordless/code
→ User receives 6-digit code
POST /auth/passwordless/verify
{
  "email": "user@example.com",
  "code": "123456"
}
→ Server issues JWT

Benefits: No password management, improved security, better user experience.

7. Multi-Factor Authentication (MFA)

JWTs can store MFA state and verification status, enabling step-up authentication.

MFA Flow

// Step 1: Password authentication
POST /auth/login
{
  "username": "user@example.com",
  "password": "password"
}

// Server issues partial JWT (MFA required)
{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "mfa_required": true,
  "mfa_methods": ["totp", "sms"]
}

// Token payload includes:
{
  "sub": "user123",
  "mfa_verified": false,
  "mfa_method": null
}

// Step 2: MFA verification
POST /auth/mfa/verify
{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "code": "123456"
}

// Server issues full access JWT
{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "mfa_verified": true
}

// Token payload now includes:
{
  "sub": "user123",
  "mfa_verified": true,
  "mfa_method": "totp",
  "mfa_verified_at": 1234567890
}

Benefits: Flexible MFA implementation, state management, step-up authentication support.

8. Token Refresh Flow

JWTs support refresh token patterns for long-lived sessions with short-lived access tokens.

Token Refresh

// Initial authentication
POST /auth/login
{
  "username": "user@example.com",
  "password": "password"
}

// Server issues access + refresh tokens
{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",  // Short-lived (15 min)
  "refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",  // Long-lived (7 days)
  "expires_in": 900
}

// Access token expires
GET /api/data
Authorization: Bearer expired_token
→ 401 Unauthorized

// Client uses refresh token
POST /auth/refresh
{
  "refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

// Server issues new access token
{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "expires_in": 900
}

// Client continues using new access token

Benefits: Better security (short-lived access tokens), improved user experience (long-lived refresh tokens), token rotation support.

9. Cross-Domain Authentication

JWTs enable authentication across different domains and services without shared cookies.

Cross-Domain Auth

// User authenticates on domain-a.com
POST https://domain-a.com/auth/login
→ Issues JWT

// User accesses domain-b.com
GET https://domain-b.com/api/data
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

// domain-b.com validates JWT
// Can verify signature independently
// No shared session store needed
// Works across different domains/subdomains

// Example: Microservices architecture
// api.example.com validates tokens from auth.example.com
// mobile-app.example.com validates same tokens
// All services trust the same issuer

Benefits: No CORS issues, no shared cookies, works across different domains, stateless validation.

10. Stateless Session Management

JWTs eliminate the need for server-side session storage, making applications more scalable.

Stateless Sessions

// Traditional session-based auth (stateful)
POST /login
→ Server creates session in database/Redis
→ Returns session ID cookie
→ Each request requires session lookup

// JWT-based auth (stateless)
POST /login
→ Server creates JWT with user info
→ Returns JWT token
→ Each request validates JWT independently
→ No database lookup needed

// Benefits:
// - No session store required
// - Horizontal scaling easier
// - Reduced database load
// - Works across load balancers
// - No sticky sessions needed

Benefits: Scalability, reduced infrastructure, no session synchronization, works with load balancers.

Best Practices for All Use Cases

Always use HTTPS to protect tokens in transit
Set appropriate expiration times for tokens
Implement token refresh mechanisms for long-lived sessions
Validate all claims and use allowlists for claim values
Never store sensitive data in JWT payloads
Use strong secrets or proper key management for signing
Implement proper token revocation mechanisms
Monitor and log authentication events

← Back to Learn Learn About Vulnerabilities →