JWT Access Tokens Explained

An access token is a credential that grants the bearer access to protected resources. When implemented as a JWT, the access token is a self-contained, signed token that carries all the information a resource server needs to authorize a request without making additional database queries or calls to the authorization server.

Anatomy of an access token:

{
  "iss": "https://auth.example.com",
  "sub": "user_abc123",
  "aud": "https://api.example.com",
  "exp": 1700001500,
  "iat": 1700000600,
  "scope": "read:data write:data",
  "roles": ["editor"]
}

The token includes standard claims (iss, sub, aud, exp) for identity and validity, plus application-specific claims (scope, roles) for authorization decisions. The resource server validates the signature, checks expiration, verifies the audience matches itself, and then uses the claims to determine whether to allow the requested operation.

Why short lifetimes matter:

Access tokens should have short lifetimes, typically 5 to 15 minutes. Because JWTs cannot be easily revoked once issued, a shorter lifetime limits the window of opportunity for an attacker who obtains a stolen token. After expiration, the client must use a refresh token to obtain a new access token, which provides a natural checkpoint for the authorization server to verify the user's current status and permissions.

What to include in access tokens:

Include only the claims that resource servers need for authorization decisions. Avoid embedding large amounts of data; every claim increases the token size, and tokens are sent with every API request. Include the user's identifier, roles or permissions, and the token's intended audience and scope. Do not include sensitive personal information, as JWTs are only encoded (not encrypted) and can be decoded by anyone who intercepts them.

Transmission and validation:

Access tokens are typically sent in the HTTP Authorization header: Authorization: Bearer eyJhbGc.... The resource server extracts the token, validates the signature using the issuer's public key (for RS256/ES256) or shared secret (for HS256), checks the exp and aud claims, and then evaluates authorization based on the embedded claims. This stateless verification is what makes JWT access tokens attractive for horizontal scaling.