IDSync — identity software buyer platform
Run Stack Finder

Standards

JSON Web Token (JWT)

A JSON Web Token (JWT) is a compact, signed (and optionally encrypted) JSON payload used to transmit claims about a user or workload between parties — most commonly as an OAuth 2.0 access token or OpenID Connect ID token.

Last reviewed 5/30/2026

Key points

  • Structure: header.payload.signature, base64url-encoded, separated by dots.
  • Signed JWTs (JWS) prove the issuer and prevent tampering — they do NOT hide the payload. Anyone can decode it.
  • Common claims: iss (issuer), sub (subject), aud (audience), exp (expiry), iat (issued at), scope, roles.
  • Validate signature, issuer, audience, and expiry on every request. Never trust a JWT just because it parses.
  • JWTs are stateless — once issued, they're valid until expiry. Use short lifetimes (5–15 min) and refresh tokens for revocability.

What is a JWT?

A JSON Web Token (JWT, RFC 7519) is a compact way to package a set of claims as a JSON object and transmit them between parties with cryptographic integrity. It's the format behind most modern OAuth 2.0 access tokens, every OpenID Connect ID token, and a huge fraction of service-to-service authentication on the internet.

A JWT looks like eyJhbGciOi...header.eyJzdWIiOi...payload.MEUCIQ...signature — three base64url-encoded segments joined by dots.

How it works

  1. An issuer (the authorization server / IdP) builds a JSON payload of claims and signs it with its private key (JWS) or encrypts it (JWE).
  2. The token is handed to a client, which presents it as a Bearer token: Authorization: Bearer eyJ....
  3. The resource server (your API) fetches the issuer's public keys from its JWKS endpoint, verifies the signature, and checks the claims.

Standard claims:

  • iss — who issued this token
  • sub — the subject (user or workload ID)
  • aud — who this token is intended for
  • exp — when it expires (Unix timestamp)
  • iat — when it was issued
  • scope / scp — OAuth scopes
  • Custom claims for roles, tenant, etc.

When buyers care

JWTs are everywhere in modern identity: every OIDC sign-in flow returns one, every OAuth-protected API consumes one, and almost every service mesh uses them for mTLS-bound workload identity.

Common misconceptions

  • "JWTs are encrypted." Signed JWTs (JWS) are not encrypted — anyone who intercepts one can decode the payload. Don't put secrets in JWT claims unless you're using JWE.
  • "Just decode it to trust it." A JWT you didn't verify is just JSON. Always validate the signature, issuer, audience, and expiry — and ideally use a vetted library.
  • "JWTs solve session management." They don't. Stateless tokens are hard to revoke. The standard pattern is short-lived access tokens + refresh tokens + a revocation store for the refresh tokens.
  • "alg: none is fine." It is not. RFC 8725 explicitly warns against accepting alg: none or letting the token dictate which algorithm verifies it. Pin the algorithm server-side.

Editorial note

If a vendor's API uses long-lived (multi-day) JWTs with no revocation story, treat that as a red flag. The right pattern is short-lived JWTs + refresh tokens + token introspection (RFC 7662) when revocability matters.

Standards & references