JWT Lifecycle

JSON Web Tokens (JWTs) are a standard mechanism for representing claims securely between a client and a server.

Mental Model

The primary benefit of JWTs is stateless authentication: once the Identity Provider (IdP) verifies a user’s credentials and signs a token, resource APIs can validate that token locally using cryptographic keys without querying the authorization server or database on every request. A client authenticates with the Auth Server, which issues a short-lived access token and a long-lived, database-backed refresh token. The client includes the access token in the Authorization header of API requests, allowing the Resource Server to statelessly verify the token signature and claims. If the access token expires, the client uses the refresh token to request a new one, rotating the refresh token to maintain security. Logging out invalidates the stateful refresh token to block new access token generation.

Components and Why They Exist

Client (Browser/App)

The client application is the browser or mobile app requesting access to protected resources. It submits login credentials, stores the access and refresh tokens in memory or secure cookies, and attaches the bearer JWT to the Authorization header as its status badge transitions from Unauthenticated to Authenticated.

Auth Server (IdP)

The Auth Server (Identity Provider) is responsible for authenticating users and issuing signed tokens. It verifies user credentials against the database, signs short-lived JWT access tokens alongside stateful refresh tokens, and rotates refresh tokens when clients request a renewal.

Resource Server (API)

The Resource Server is the backend API hosting protected data that the client wants to access. It performs stateless validation of the incoming JWT by verifying the cryptographic signature, expiration timestamp, and audience claims locally, returning 200 OK for valid tokens or 401 Unauthorized when a token is tampered with or expired.

Database (Users)

The user database is the persistent store for user credential records and stateful refresh token status. It answers credential verification queries during login and updates refresh token rotation and revocation states during token refresh and logout steps.

Edge Cases and Misconceptions

• Misconception: JWT payload data is encrypted: A JWT is base64url encoded, NOT encrypted. Anyone who intercepts the token can decode it to view the payload claims. Sensitive data (like passwords or personally identifiable information) should never be stored in a standard JWT payload.
• Misconception: A stateless JWT can be easily revoked: Because resource servers validate JWTs statelessly (locally by signature), there is no simple way to revoke an active access token before it naturally expires. Access tokens must have a very short lifespan (e.g., 5 to 15 minutes) to minimize the abuse window.
• Edge Case: Token Tampering: If an attacker alters any claims in the JWT payload (e.g., modifying the user role from user to admin), the signature validation on the Resource Server will fail because the signature was generated using the original payload bytes.
• Edge Case: Token Replay: If a JWT is intercepted by a malicious third party, they can replay it to access the APIs. To mitigate this, runtimes must enforce HTTPS, use secure cookies with HttpOnly/SameSite attributes, and assign short token lifespans.