JWT authentication flow explained

October 25, 2026 · 14 min read

JWT authentication is a sequence of trusted handoffs: the user proves identity to an authorization server, receives a signed token, and presents that token to resource servers that verify signature and claims without calling the login database on every request. Understanding each hop prevents “works in Postman” integrations that skip validation.

Actors: client, authorization server, resource API

Client - browser SPA, mobile app, or backend service acting on behalf of a user.
Authorization server - issues tokens after OAuth 2.0 / OpenID Connect flows (Auth0, Keycloak, Cognito, custom).
Resource server - your API; validates JWT and maps sub to local permissions.

Public clients use Authorization Code with PKCE: redirect to login, user authenticates, redirect back with a one-time code exchanged server-side for tokens. Confidential clients may use client credentials for machine-to-machine tokens without a user sub.

POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=...&redirect_uri=...&client_id=...

JWT returned from the token endpoint

The token response includes access_token (often a JWT), token_type: Bearer, expires_in, and sometimes refresh_token and id_token (OpenID). Decode samples with the JWT decoder to see iss, aud, scopes, and exp.

Calling APIs with Bearer JWT

Clients attach Authorization: Bearer <jwt>. The API validates signature with the issuer JWKS, checks exp and audience, then authorizes the route. Stateless verification scales horizontally; heavy session lookups move to issuance time only.

Refresh tokens and logout

Short access JWTs limit exposure; refresh tokens rotate in secure storage to obtain new access tokens. Logout revokes refresh tokens server-side because access JWTs remain valid until exp. Document this for security reviewers comparing JWT flows to server sessions.

FAQ

Is the access token always a JWT?: No. Some servers return opaque access tokens; resource APIs introspect them. Many cloud providers use JWT access tokens by default.
Where does the client store the JWT?: Memory plus refresh in HttpOnly cookies is common for SPAs; mobile uses secure storage. Avoid localStorage for high-value tokens without extra hardening.
Who signs the JWT?: The authorization server with its private key (RS256) or shared secret (HS256) depending on deployment.

Browse all tools