Wiki · Concept · Last reviewed June 25, 2026

JSON Web Tokens

JSON Web Tokens are compact claim containers that can be signed, integrity protected, or encrypted; in agent systems they often carry identity, delegation, audience, and authorization evidence.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: AI agents, JWT, JOSE, OAuth, identity, authorization

Definition

JSON Web Token, usually abbreviated JWT, is the IETF token format defined by RFC 7519: a compact, URL-safe way to represent claims transferred between two parties. Those claims are encoded as JSON and carried either as the payload of a JSON Web Signature structure or as the plaintext of a JSON Web Encryption structure.

A JWT is not a login ticket by itself. It is a claim format. Whether it proves anything depends on the issuer, signature or encryption method, key discovery, audience, expiration, token profile, validation rules, and the resource server policy that decides what to do with it.

For AI agents, JWTs matter because delegated tool calls often move through identity and authorization systems that speak JOSE and OAuth. A token may say which user, client, agent, authorization server, audience, scope, or actor is involved. The system still must validate and enforce those claims.

Snapshot

How It Works

A typical JWT has a header, payload, and signature or encryption data, serialized in compact form. The payload contains claims. RFC 7519 registers common claim names such as iss for issuer, sub for subject, aud for audience, exp for expiration, nbf for not-before time, iat for issued-at time, and jti for token identifier.

JSON Web Signature, RFC 7515, protects integrity and can authenticate the signer. JSON Web Encryption, RFC 7516, protects confidentiality. JSON Web Key, RFC 7517, represents cryptographic keys used by these systems. Together these sit inside the JOSE family of specifications.

Many deployments use JWTs inside larger profiles. RFC 9068 defines a JWT profile for OAuth 2.0 access tokens and gives those tokens the explicit type at+jwt. RFC 7523 defines JWT bearer assertions for OAuth client authentication and authorization grants. OpenID Connect Core defines the ID Token as a JWT carrying claims about an authentication event. JAR, JARM, SD-JWT VC, and Entity Attestation Token all use JWT-related machinery for more specific jobs.

Base64url encoding is not secrecy. A signed JWT can still expose its claims to anyone who sees it. Encryption, claim minimization, audience restriction, and careful logging are separate design choices.

Boundary Tests

Not every JWT is an access token. A JWT can be an ID Token, access token, client assertion, request object, introspection response, attestation token, verifiable credential, or custom artifact. Each profile has different validation rules.

Signed is not encrypted. JWS protects integrity and signer authenticity. It does not hide payload claims from clients, logs, proxies, browser extensions, or model-visible traces.

Encrypted is not accepted. JWE protects confidentiality in transit between parties that hold the right keys, but the recipient still has to validate issuer, audience, time, token type, and local policy after decryption.

An ID Token is not API authority. OpenID Connect ID Tokens are for authentication results at a relying party. They should not be treated as API bearer tokens or proof that an agent may perform a later action.

A JWT introspection response is not the introspected token. RFC 9701 secures the response from an introspection endpoint; it does not mint a new access token for the resource server to replay.

A valid signature is not a local allow decision. The resource server still needs the right issuer, key, audience, subject or actor, scope, token profile, confirmation proof if sender-constrained, and policy rule.

Current Context

As of this June 25, 2026 review, RFC 7519 remains the base JWT standard and RFC 8725 remains the published Best Current Practice for secure JWT deployment. The OAuth working group also has an active rfc8725bis draft; draft-ietf-oauth-rfc8725bis-06 was published on June 19, 2026 and is still work in progress rather than a replacement RFC.

OAuth practice has moved toward sharper token boundaries. RFC 9700, published in January 2025, recommends sender-constrained and audience-restricted access tokens for reducing replay and says resource servers must refuse access tokens intended for another audience. RFC 9701, also published in January 2025, standardizes a JWT-secured token introspection response for deployments that need signed or encrypted introspection results.

Agent and tool protocols make these distinctions more important. A browser agent, MCP connector, coding agent, or hosted workflow may hold several JWT-shaped artifacts at once: user authentication, tool access, workload identity, attestation, and audit evidence. Treating them as interchangeable creates token confusion, overbroad authority, and avoidable privacy exposure.

Agent Context

Agent workflows create long chains: a human authorizes a task, a model selects a tool, a runtime calls a connector, and a resource server decides whether to honor the request. JWTs can preserve evidence across that chain if the claims are narrow, validated, and logged.

The useful questions are concrete. Who issued this token? Which client or agent is it for? Which subject, actor, or workload does it represent? Which resource server is the audience? Which scope, authorization detail, assurance level, or confirmation key is present? When does it expire? Was it revoked, introspected, exchanged, downscoped, or superseded?

The dangerous pattern is possession-only authorization. A tool server sees a token-shaped string and accepts it without checking issuer, audience, time, signature, key, token type, or policy. In an agent setting, a copied token from logs, traces, browser storage, screenshots, prompt transcripts, or a compromised connector can become live authority.

JWT parsing should not move into prompt logic. A model may summarize a token's visible claims for debugging only under strict redaction rules, but policy decisions belong to authorization and resource-server code with configured issuers, keys, profiles, and denial behavior.

Governance and Safety

RFC 8725 is the JWT Best Current Practices document. It updates RFC 7519 with implementation and deployment guidance, including algorithm verification, key selection, explicit typing, claim validation, and avoiding confusion between different kinds of JWTs. The 2026 rfc8725bis draft adds newer threats such as additional format-confusion and decompression concerns, but production controls should still cite the published RFC plus the draft's status when relying on draft text.

Governance should treat a JWT as evidence that must be appraised, not as a conclusion. A signed token from the wrong issuer, a token with the wrong audience, an expired token, a token with missing subject context, or a token intended for one profile but accepted in another can all be well-formed and still unsafe.

Governed systems should maintain issuer-to-key and issuer-to-metadata bindings. A token's kid, jku, x5u, or discovery-derived jwks_uri should not let untrusted token input choose arbitrary key material or trigger unsafe network fetches.

Privacy governance is as important as signature verification. JWTs often carry subject identifiers, emails, roles, groups, entitlements, assurance claims, and tenant context. Those claims should be minimized, encrypted or made opaque where needed, and kept out of model context, analytics, support bundles, and ordinary logs.

Audit records should preserve token metadata, not full bearer tokens: issuer, subject where appropriate, audience, client or agent identifier, key identifier, algorithm, token type, expiration, scope or authorization detail, confirmation claim if used, validation result, and downstream action.

Minimum Validation Record

A serious JWT-using agent connector or resource server should leave enough evidence for review without storing reusable token material.

Failure Modes

Algorithm confusion. The verifier lets the token choose an unsafe or unexpected algorithm, accepts none, or mixes symmetric and asymmetric keys incorrectly.

Key confusion. The verifier trusts an attacker-controlled jku, x5u, or loosely matched kid, so the issuer-key relationship is not actually controlled by the deployment.

Cross-JWT confusion. A resource server accepts an ID Token, client assertion, request object, verifiable credential, or introspection response as if it were an access token for the requested API.

Audience confusion. A token valid for one resource server is accepted by another because the receiver ignores or misinterprets aud, resource indicators, or protected-resource metadata.

Subject confusion. The system merges a human user, OAuth client, service account, agent, connector, or workload into one ambiguous sub value and cannot reconstruct who acted.

Bearer replay. A signed JWT access token leaks through logs, prompts, browser storage, traces, or support artifacts and is replayed because no sender constraint or revocation path blocks reuse.

Overstuffed claims. Tokens carry unnecessary identity or authorization data by value, increasing privacy exposure and correlation risk across tools and resource servers.

Prompt-side validation. A model reads or reasons about JWT claims and the system treats that as authorization, bypassing configured verifier code, issuer metadata, and resource-server policy.

Defense Pattern

Source Discipline

Claims about JWTs should name the profile and use case: ID token, OAuth access token, JWT bearer grant, request object, response object, SD-JWT VC, EAT, token-status token, introspection response, or custom token. The same compact syntax can carry different trust semantics. Do not collapse JWT into OAuth, OpenID Connect, bearer tokens, API keys, legal consent, or agent approval.

Use exact source labels. RFC 7519 defines the JWT format. RFCs 7515, 7516, and 7517 define JWS, JWE, and JWK. RFC 8725 defines published JWT best current practices. RFC 9068 defines the OAuth JWT access token profile. RFC 7523 defines JWT bearer assertions. RFC 6750 defines bearer token use. RFC 7662 and RFC 9701 define token introspection and JWT-secured introspection responses. OpenID Connect Core defines ID Tokens.

For implementation claims, preserve the issuer, profile, date, algorithm policy, key source, audience rule, sender-constraint method if any, introspection or revocation path, and tests for wrong-token-profile acceptance. "Uses JWT" is not a security property unless the validation boundary is named.

Spiralist Reading

Spiralism reads a JWT as a small envelope of institutional speech. It says: this issuer asserts these claims for this audience until this time.

The signature is not a blessing. It is a receipt with a key attached. The moral and operational question is still whether the receiving system should believe it, limit it, log it, or refuse it.

Open Questions

Sources

Return to Wiki