Wiki · Concept · Last reviewed June 25, 2026

OAuth JWT Bearer Grant

The OAuth JWT Bearer profile lets a client present a signed JWT assertion to the token endpoint as an authorization grant, as client authentication, or as both.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, OAuth, JWT bearer, assertions, audit trails

Definition

The OAuth JWT Bearer profile is the Standards Track profile defined in RFC 7523, JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants, by Michael B. Jones, Brian Campbell, and Chuck Mortimore. RFC 7523 was published in May 2015. It profiles the RFC 7521 OAuth assertion framework for JWTs.

The profile defines two related but separable uses. A JWT can be used as an authorization grant to request an OAuth access token. A JWT can also be used as client authentication at the token endpoint. RFC 7523 says client authentication using a JWT is only an authentication method and must be combined with some grant type to form a meaningful token request.

For AI agents, this pattern matters when a workflow, tool broker, workload identity system, or service bridge uses a signed assertion from one trust domain to obtain an access token in another. It is not a browser consent flow, and it is not the same as handing a model a long-lived API key.

How It Works

When a JWT is used as an authorization grant, the client sends a token request with grant_type set to urn:ietf:params:oauth:grant-type:jwt-bearer. The assertion parameter must contain a single JWT. The scope parameter can be used to request scope. Client authentication is optional for the JWT authorization grant unless authorization server policy requires it.

When a JWT is used for client authentication, the token request includes client_assertion_type set to urn:ietf:params:oauth:client-assertion-type:jwt-bearer, and client_assertion contains one JWT. This mechanism can be used with an authorization code grant, Client Credentials Grant, JWT Bearer grant, or another appropriate grant.

RFC 7523 requires the JWT to contain iss, sub, aud, and exp claims. It may contain nbf, iat, jti, and other claims. For client authentication, sub must be the OAuth client identifier. The aud claim identifies the authorization server, and the authorization server must reject a JWT that does not identify it as an intended audience.

The JWT must be digitally signed or protected with a MAC, and the authorization server must reject invalid signatures or MACs. Invalid authorization-grant assertions produce invalid_grant; invalid client-authentication assertions produce invalid_client. RFC 7523 also registers both JWT bearer URNs in the OAuth URI registry.

Agent Context

Agent systems often cross identity domains: a cloud scheduler invokes a tool gateway, a coding agent asks for access to a build system, or an enterprise connector exchanges a workload assertion for an access token. JWT Bearer is one way to express that an upstream identity provider, attester, or federation service has made a signed claim that the authorization server is willing to trust.

The danger is over-reading the assertion. A signed JWT can say who issued it, who or what it is about, who should consume it, and when it expires. It does not by itself decide whether the resulting agent action is wise, least-privilege, or approved for the present task.

This distinction is important for governance. JWT Bearer can reduce secret sharing and make trust relationships explicit, but it can also hide responsibility if every workflow exchanges assertions through one generic broker without preserving the run, operator, resource, and purpose.

Governance and Safety

RFC 7523 says interoperable deployments need agreement on issuer and audience identifiers, token endpoint location, signature or MAC keys, one-time use restrictions, maximum JWT lifetime, and subject and claim requirements. It also says replay protection is optional, so a deployment that needs replay resistance must make that policy explicit, commonly through short lifetimes and jti tracking.

Audit trails should preserve the authorization server, token endpoint, assertion issuer, assertion subject, audience, expiration window, key identifier, assertion use case, requested scope, granted scope, client authentication status, replay decision, token result, agent run, workflow owner, and resource server. Logs should not store full assertions, private keys, access tokens, or refresh tokens.

Failure modes include accepting the wrong audience, trusting stale assertions, missing key rotation, allowing excessive JWT lifetimes, failing to distinguish JWT-as-grant from JWT-as-client-authentication, and assuming that a signed assertion is equivalent to user consent.

Defense Pattern

Source Discipline

Claims about the OAuth JWT Bearer Grant should identify the assertion issuer, subject, audience, expiration, signing or MAC method, key, token endpoint, grant type, client authentication status, scope, replay policy, and token response. Do not collapse it into OAuth Token Exchange, JWT-Secured Authorization Requests, OAuth Client Credentials Grant, a generic service account, or a legal conclusion that a user consented.

Spiralist Reading

Spiralism reads the JWT Bearer grant as a sealed letter crossing jurisdictions. The receiving institution does not see a user click; it sees a signed statement from a trusted issuer and decides whether to exchange that statement for local power.

The seal is not the whole truth. A serious system records why the letter was written, who may rely on it, how long it lives, and what power it unlocks.

Open Questions

Sources

Return to Wiki