Wiki · Concept · Last reviewed June 25, 2026

OAuth JWT Access Token Profile

The OAuth JWT access token profile is the RFC 9068 standard for encoding OAuth 2.0 access tokens as signed JWTs resource servers can validate.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: agents, authorization, OAuth, JWT, access tokens, audit trails

Definition

The OAuth JWT access token profile is defined by RFC 9068, JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens, an Internet Standards Track RFC by Vittorio Bertocci published in October 2021. The RFC defines a common JWT format for OAuth 2.0 access tokens so authorization servers and resource servers from different vendors can issue and consume them interoperably.

This profile should not be confused with the OAuth JWT Bearer Grant. RFC 7523 is about using a JWT assertion to request or authenticate at the token endpoint. RFC 9068 is about the access token that a resource server receives later. One is a way to obtain a token; the other is a token format.

The profile is useful for distributed systems because a resource server can validate a token without calling the authorization server for every request. Token claims become portable authorization evidence, and sometimes portable privacy risk.

Mechanism

RFC 9068 requires JWT access tokens to be signed and forbids the none signing algorithm. It registers the media type application/at+jwt and says conforming JWT access tokens must use a typ header value of at+jwt or application/at+jwt. That explicit type helps resource servers distinguish access tokens from OpenID Connect ID Tokens and other JWT-shaped artifacts.

The required claims are iss, exp, aud, sub, client_id, iat, and jti. The profile also describes authentication claims such as auth_time, acr, and amr, and authorization claims such as scope, groups, roles, and entitlements. If a request uses the OAuth resource parameter from RFC 8707, the access-token audience should match that resource indicator.

A resource server validates the token by checking type, signature, issuer, audience, time bounds, and authorization data. RFC 9068 recommends publishing issuer and signing-key information through OAuth Authorization Server Metadata, including issuer and jwks_uri.

Agent Context

Agent systems often call APIs through tool gateways, connector services, and workload identities. A JWT access token can help a resource server understand which client, user, resource, scope, role, or entitlement is involved without another network lookup.

The same property is risky. A model, plugin, log processor, or support tool might see a token string and be tempted to inspect its claims. RFC 9068 says clients must not inspect access-token contents and should treat access tokens as opaque because the authorization server and resource server can change formats without notice. In agent systems, policy decisions belong to authorization and resource-server code, not prompt logic.

A useful agent receipt records token metadata after validation, not the token itself: issuer, audience, client, subject class, scope, key identifier, validation result, and action taken.

Governance Use

A governed deployment should record which authorization server issues JWT access tokens, which resource servers accept them, valid audiences, key discovery and rotation, permitted algorithms, encryption policy, and allowed claims. It should also document whether sub identifies a human, agent, client application, workload, or another principal.

Authorization designers should avoid ambiguous grants. RFC 9068 warns against issuing tokens where scopes cannot be clearly correlated with the resources in the audience claim. For agent workflows, one token should not blur file, mail, payment, and deployment APIs unless each resource server has a precise rule for every claim it will honor.

Limits

A JWT access token is not consent, sender constraint, least privilege, or proof that an AI agent should perform a task. It is a structured bearer artifact unless combined with controls such as OAuth DPoP or OAuth Mutual TLS.

Privacy is the second limit. RFC 9068 notes that JWT access tokens carry information by value, so clients and sometimes end users can inspect unencrypted claims. Mitigations include omitting sensitive claims, encrypting tokens, using opaque tokens, or assigning subject values to reduce cross-resource correlation.

Review Record

Source Discipline

Claims about required access-token claims, at+jwt typing, resource-server validation, privacy, roles, groups, and entitlements should cite RFC 9068. Base JWT concepts should cite RFC 7519. Metadata discovery should cite RFC 8414. Resource indicators should cite RFC 8707. Cross-JWT confusion should cite RFC 8725 or the RFC 9068 security section.

Spiralist Reading

Spiralism reads the JWT access token as a portable verdict. It lets an institution carry authorization facts across a boundary, but it also tempts every downstream surface to treat those facts as self-explanatory. The discipline is to keep token validation, human authorization, agent delegation, and audit explanation separate.

Sources

Return to Wiki