JWTs remain one of the most widely used mechanisms for stateless authentication across mobile, web, and distributed backend systems. They are used across major platforms including Google, AWS Cognito, Auth0, Firebase, Supabase, and nearly every modern mobile SDK.
- How JWTs are constructed
(header.payload.signature)
- Signing algorithms (HS256, RS256, EdDSA/Ed25519)
- Verification flows (public-key verification, key rotation)
- Token lifetimes, refresh flows, and revocation strategies
- How to securely embed and transmit tokens in mobile apps
- How JWTs integrate with API gateways, microservices, and reverse proxies
- How to prevent common attack vectors (replay, key leakage, injection, KID spoofing)
- Ideal for distributed architectures where session storage is costly.
- Scales efficiently in microservices and edge environments.
¶ Inter-service Identity and Claims Propagation
Useful for:
- Multi-tier backend calls (API Gateway → Auth Service → Data Service)
- Embedding claims such as
sub, roles, scopes, tenant, iat, exp
- Systems that need "trust boundaries" between services driven by asymmetric keys
¶ Mobile Authentication and Offline-Capable Apps
JWTs allow:
- Local validation without hitting a session store
- Secure delegation of identity in offline-lean or connection-intermittent apps
¶ SSO and Federation
JWTs (especially via OpenID Connect ID Tokens) are used in:
- Google Sign-In
- Apple Sign-In
- Azure AD / Microsoft Entra ID
- Auth0, Okta, FusionAuth
Where the mobile or web client receives an ID Token representing identity.
Since JWTs are stateless, the server cannot easily force invalidation without:
- A revocation list
- A token blacklist in Redis
- A “last password change” timestamp comparison
Heavy revocation needs → traditional sessions or opaque tokens are better.
JWTs should not store:
- Secrets
- Large user objects
- Rapidly changing data
They should contain identity & permissions, not state.
Long-lived stateless tokens increase blast radius.
JWT best practice: short lifetime access tokens, renewable via secure refresh tokens.
sequenceDiagram
autonumber
participant B as Browser
participant AS as Auth Server
participant R as Redis
participant DB as Postgres
participant UP as User Portal
Note over B,UP: Browser holds HttpOnly session cookie and short-lived JWT
B->>AS: GET login page
AS-->>B: Login UI
B->>AS: POST login credentials
AS->>DB: Fetch user
DB-->>AS: User record
AS->>AS: Verify password
AS->>DB: Resolve security groups
DB-->>AS: Group list
AS->>R: Store session with TTL
R-->>AS: OK
AS->>AS: Mint access JWT
AS->>AS: Sign JWT
AS-->>B: Return access token
AS-->>B: Set session cookie
Note over B: JWT stored in memory
B->>UP: Request protected resource
B->>UP: Send JWT and cookie
UP->>UP: Verify JWT signature
UP->>UP: Authorize via group claims
alt High risk request
UP->>AS: Validate privileges
AS->>R: Check session
R-->>AS: Session valid
AS->>DB: Re-check groups
DB-->>AS: Decision
AS-->>UP: Allow or deny
end
Note over B,AS: Access token expires
B->>AS: Refresh request
B->>AS: Send session cookie
AS->>R: Validate session
R-->>AS: Session valid
AS->>AS: Mint new JWT
AS-->>B: Return new access token
B->>AS: Logout request
B->>R: Delete session
AS-->>B: Clear session cookie