A platform uses signed tokens for service-to-service and client authentication. Which properties must be verified on every use, and what goes wrong when they are not?

What must be verified, every time

1. The signature, against an expected key. And critically, the algorithm must be pinned by the verifier, not taken from the token. Accepting the token's own algorithm claim is how libraries have historically been tricked into accepting unsigned tokens or verifying an asymmetric token with the public key as an HMAC secret.

2. Expiry, with a small tolerance. An unexpired-forever token is a permanent credential.

3. Issuer and audience. A token issued for one service must not be accepted by another. Without audience checking, a token obtained legitimately from a low-privilege service is replayable against a high-privilege one — a privilege escalation through an entirely valid token.

4. Key identifier, resolved against a trusted key set with caching that respects rotation. Fetching keys per request is a hard dependency on the identity provider on the hot path; never refreshing means rotation breaks everything at once.

5. Claims used for authorization, revalidated against current state where they matter. A token asserting a role captured at issue time is stale by definition.

What goes wrong

The revocation problem, which is inherent. A stateless signed token is valid until it expires, by design. If a user is removed, a key is compromised, or permissions change, existing tokens remain valid. There are only three resolutions, each with a cost:

• Short expiry (minutes), so the window is bounded. Costs refresh traffic and requires the refresh path to be reliable.
• A revocation list checked on the hot path, which reintroduces the state the token was meant to avoid — but the list is small and cacheable, which usually makes this acceptable.
• Accepting the window, which is a legitimate choice if it is decided rather than discovered.

Sensitive data in the payload. Tokens are base64-encoded, not encrypted. Anything in the payload is readable by anyone holding the token, including the browser and any intermediary that logs it.

Tokens in logs and URLs. A token in a query string ends up in access logs, browser history and referrer headers. This is one of the most common real-world credential leaks and it is entirely preventable.

Using tokens as session cookies without the cookie protections — HttpOnly, Secure, SameSite — which reintroduces cross-site risks that cookies had already solved.

The design guidance

Use short-lived signed tokens for service-to-service calls, where the parties are known and expiry can be short. For user sessions, an opaque session identifier backed by server-side state is frequently the better choice: revocation is immediate, no sensitive data is exposed, and the lookup cost is a cache hit.

The stateless property that makes signed tokens attractive is precisely what makes revocation hard, and revocation is the property that matters during an incident.