JSON Web Tokens

A JSON Web Token (JWT) is a standardized container for claims exchanged between systems. Claims can identify a user or application, name the issuing authority, specify intended recipients, and define validity times. JWT is a token format, not an authentication protocol or an authorization policy. OAuth 2.0 access tokens can use JWT format, while OpenID Connect ID tokens use JWTs to communicate authentication information to clients.

The signed JWT commonly used by cloud APIs has three base64url-encoded segments separated by periods: a header, a payload, and a signature. The header identifies the signing algorithm and may include a key identifier, or kid. The payload contains claims. A valid signature provides integrity and authenticity under the verifier's configured trust model, but it does not conceal the payload. Anyone holding an ordinary signed JWT can decode its claims, so passwords, secrets, and unnecessary personal information should not appear there. Encrypted JWTs also exist, but encryption must not be assumed.

In a typical application, a client authenticates with an identity provider and receives an access token. It sends that token to an API using the Authorization header with the Bearer scheme, over HTTPS. Bearer means that possession is sufficient to present the credential; an attacker who steals it can generally replay it until it expires or an applicable revocation mechanism rejects it. Tokens should not appear in URLs, application logs, or error messages. Browser storage choices must account for script-based theft and, when cookies are used, cross-site request forgery.

A resource server must verify the signature using trusted keys and an explicitly permitted algorithm. It must also validate the expected issuer, expiration, applicable not-before time, intended audience or required client binding, and token purpose. Do not trust a token simply because its signature is mathematically valid: it might belong to another application or be an ID token rather than an API access token. Retrieve verification keys only from trusted configuration, commonly an issuer's JSON Web Key Set endpoint, and support key rotation with controlled caching.

Authentication establishes who presented the request; authorization determines what that identity may do. For example, an orders API might require an orders.read scope and then verify that the requested order belongs to the authenticated subject or tenant. A valid token alone does not grant access to every record. With Amazon Cognito and an Amazon API Gateway HTTP API, an issuer can provide tokens while a JWT authorizer validates them and checks configured route scopes. Backend code must still enforce resource-level business permissions.

Local signature verification reduces session-store lookups and supports horizontally scaled services. The trade-off is that claims can become stale: removing a role or signing a user out does not necessarily invalidate an already issued token at a locally verifying API. Short-lived access tokens limit this window, while refresh-token controls, deny lists, or additional state checks address stronger revocation requirements at an operational cost. Finally, JWTs are not AWS access keys: calling most AWS service APIs requires AWS credentials and Signature Version 4, even when a JWT was used earlier to authenticate the user.