Standard JWTs (JWS) are signed, not encrypted: the payload is only Base64URL-encoded and anyone holding the token can read it. Signing guarantees integrity and authenticity, not confidentiality. If claims themselves must stay secret, the JWE variant encrypts the payload, but the more common rule is simply never to put sensitive data in a JWT.

What is the difference between a JWT and a session cookie?

A session cookie is a random reference to state stored on the server, so revocation is instant but every request needs a session lookup. A JWT carries the state within itself, so validation is local and fast but the token stays valid until expiry. Many systems combine them: a JWT from the identity provider establishes the login, then the application manages its own session.

How long should a JWT be valid?

Access tokens should live minutes, commonly 5 to 60, so that a stolen token has a short useful life. Longer sessions are maintained through refresh tokens, which the identity provider can revoke and which trigger a fresh policy evaluation on every renewal. Long-lived access tokens trade away the main defense JWT deployments have against theft.

JSON Web Token (JWT)

What is a JSON Web Token (JWT)?

A JWT is a compact, digitally signed token that carries identity claims as JSON, letting services verify who a request comes from without a database lookup.

Last updated: 14 July 2026

How JWTs work

A JWT is three Base64URL-encoded parts joined by dots: header.payload.signature. The header names the signing algorithm, such as RS256. The payload holds claims: registered ones like iss (issuer), sub (subject), aud (audience), exp (expiry), and iat (issued at), plus custom claims such as email, roles, or tenant. The signature covers the first two parts, so any tampering invalidates the token.

Signing comes in two families. HMAC (HS256) uses one shared secret for both signing and verification, which suits a single application. Asymmetric algorithms such as RSA (RS256/384/512) or ECDSA sign with a private key while anyone holding the public key can verify, which is why identity providers publish their keys in a JWKS endpoint and every microservice can validate tokens independently. Crucially, a standard JWT is signed but not encrypted: anyone who obtains it can read the payload, so secrets never belong in claims.

Why JWTs matter

JWTs are the workhorse token format of modern identity. OpenID Connect ID tokens are JWTs by specification, OAuth 2.0 access tokens frequently are, and APIs across the industry accept them as bearer credentials. Their appeal is statelessness: a service validates the signature, checks expiry and audience, and trusts the claims without a session store or a network call, which fits microservices and horizontal scaling naturally.

Statelessness is also the trade-off to manage. A signed token remains valid until it expires, so revoking access mid-lifetime requires extra machinery. The practical pattern is short-lived access tokens, minutes rather than hours, refreshed from the identity provider, which re-evaluates the user's status at each refresh. Anything requiring instant revocation on its own is better served by server-side sessions or token introspection.

JWTs in practice

Validation discipline is everything. Verify the signature against the issuer's published keys, pin the expected algorithm rather than trusting the token's header (the alg=none and algorithm-confusion attacks exploit exactly this), and check iss, aud, and exp on every request. Keep tokens out of browser local storage where scripts can read them; httpOnly cookies or in-memory storage are safer homes.

Keep payloads lean, since the token travels with every request, and rotate signing keys on a schedule that clients can follow via JWKS. Monosign issues JWTs signed with RSA-SHA256, SHA384, or SHA512 for its OIDC and API integrations, with published keys that services validate independently.

Frequently asked questions

Are JWTs encrypted?: Standard JWTs (JWS) are signed, not encrypted: the payload is only Base64URL-encoded and anyone holding the token can read it. Signing guarantees integrity and authenticity, not confidentiality. If claims themselves must stay secret, the JWE variant encrypts the payload, but the more common rule is simply never to put sensitive data in a JWT.
What is the difference between a JWT and a session cookie?: A session cookie is a random reference to state stored on the server, so revocation is instant but every request needs a session lookup. A JWT carries the state within itself, so validation is local and fast but the token stays valid until expiry. Many systems combine them: a JWT from the identity provider establishes the login, then the application manages its own session.
How long should a JWT be valid?: Access tokens should live minutes, commonly 5 to 60, so that a stolen token has a short useful life. Longer sessions are maintained through refresh tokens, which the identity provider can revoke and which trigger a fresh policy evaluation on every renewal. Long-lived access tokens trade away the main defense JWT deployments have against theft.