---
{
  "title": "JSON Web Token (JWT) security",
  "summary": "JWTs carry claims in a standardized token format.",
  "topic": "foundations",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: JSON Web Token",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet.html"
    },
    {
      "title": "IETF RFC 8725: JSON Web Token Best Current Practices",
      "url": "https://www.rfc-editor.org/rfc/rfc8725.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

JWTs carry claims in a standardized token format. A signed token protects integrity but does not inherently encrypt its contents. A receiver must verify the expected algorithm, issuer, audience, and relevant lifetime claims before using the token within a particular authorization policy.

## A practical example

An API validates a token issued for that API rather than accepting any valid token from the identity provider. It checks expiration and constrains algorithms through configuration, then separately decides whether the subject may access the requested record.

## What to check

Use maintained verification libraries, protect keys, validate required claims, and plan revocation or short lifetimes appropriate to the use case. Avoid placing unnecessary secrets in readable token claims.

## A common pitfall

Decoding a JWT is not verification. A mathematically valid signature also does not prove that the token was intended for this service or operation.

## Think it through

Why check audience after verifying the signature?

**Answer:** A genuine token issued for a different recipient should not automatically authorize access to this API.

## Verification depends on the recipient's contract

A fictional analytics API receives tokens from an identity service that also serves an unrelated file-sharing app. A valid signature proves that a configured key signed particular content. The analytics API still needs to know that the issuer is trusted for its purpose and that the token is addressed to it. Accepting every signed token from the provider would erase the distinction between the two applications.

Claims should be interpreted under an explicit token profile. Decide which issuer, audience, lifetime values, and token purpose are required. Configure supported algorithms rather than allowing an incoming header to choose an unexpected verification approach. Key selection is also part of the trust boundary; do not fetch arbitrary key locations merely because a token names them.

An ordinary signed JWT is readable by anyone who obtains it. Encoding is not encryption. Avoid placing credentials, unnecessary personal data, or internal secrets in claims. Even harmless-looking claims can expose information if tokens enter browser history, analytics, or application logs.

## Review acceptance and rejection together

For the analytics example, prepare a token intended for the API and a token intended for the file-sharing app using a controlled test identity system. State why one should be accepted and the other rejected. Include expired and otherwise malformed test tokens through the library's supported test facilities.

After verification, the application still evaluates permissions on the requested resource. A token naming a genuine user does not permit every operation that user can describe in a request. Keep token verification and business authorization visible as separate decisions. The resulting design is easier to review than treating successful decoding as a universal access grant.

## Related concepts

- [[digital-signatures]]
- [[authorization]]
- [[identity-federation]]