OAuth·for·Agents

Reference · August 2026

The parts bin

Everything the seven scenarios use, grouped by the job it does rather than by document number. Statuses are current as of August 2026 and will move. The IETF datatracker is always the authority.

RFC published   RFC queue approved, awaiting a number   WG draft adopted by the working group   Individual proposed, not adopted

Group one

Giving the agent an identity

How software proves it is what it claims to be, without a shared secret.

Client ID Metadata Document WG draft

draft-ietf-oauth-client-id-metadata-document

The client's ID is an HTTPS URL serving its own metadata. No registration call, no shared secret, and one identifier that means the same thing at every authorization server. Used in scenario 02.

JWT Profile for Client Authentication and Authorization Grants RFC 7523

Two things at once: private_key_jwt client authentication, and the JWT bearer grant identity chaining is built on. Used in 00 and 05.

Mutual TLS Client Authentication and Certificate-Bound Tokens RFC 8705

Client authentication and sender-constrained tokens at the transport layer. The right answer where your infrastructure already does mTLS.

Attestation-Based Client Authentication WG draft

draft-ietf-oauth-attestation-based-client-auth

The environment vouches for the client instance, so it needs no long-lived credential on disk. Where posture assessment reaches the token endpoint. Doing it for a stranger is still open.

SPIFFE Client Authentication WG draft

draft-ietf-oauth-spiffe-client-auth

Lets a workload authenticate using the SPIFFE identity its platform already issued. If your agents run in a mesh that does workload identity, this is the bridge to an OAuth token.

Dynamic Client Registration RFC 7591

The original answer to unregistered clients, and what the first wave of MCP servers used. Increasingly the fallback rather than the plan, because the identifiers it mints are meaningless elsewhere.

Group two

Making tokens worth less to steal

Agents leak credentials in ways backends don't. These make a leaked token boring.

DPoP RFC 9449

Application-layer proof of possession. The token is bound to a key the client holds, and every request carries a fresh signature over the method, URL and token. The highest-value single change on this list.

Resource Indicators RFC 8707

The client names which API a token is for and the server audience-binds it. The structural defense against the confused deputy: an agent holding six tokens can't be tricked into a useful mistake.

PKCE RFC 7636

Binds an authorization code to the client that requested it. Mandatory in OAuth 2.1.

Pushed Authorization Requests RFC 9126

The client sends request parameters directly to the server and gets back a reference, so nothing sensitive passes through a browser and the consent screen renders from what the server received. Essential once you're sending authorization details.

Authorization Server Issuer Identification RFC 9207

Puts the issuer in the authorization response, so a client talking to several servers can't be fed one from the wrong server. One parameter, one attack class.

JWT Profile for Access Tokens RFC 9068

A standard shape for a JWT access token, so resource servers validate locally and agree on what the claims mean.

Group three

Finding out where to authenticate

Two well-known documents that turn a bare URL into a working flow.

Protected Resource Metadata RFC 9728

An API declares which authorization server protects it, which scopes exist, and what token types it needs, all discoverable from a 401.

Authorization Server Metadata RFC 8414

Endpoints, supported grants, authentication methods and algorithms: everything an agent needs to construct a correct request without documentation.

Group four

Reaching a human who isn't at a browser

Consent was designed as a redirect. Agents can't do redirects, and their users are somewhere else.

Device Authorization Grant RFC 8628

Show a code, let the user approve on another device, poll for the result. It established authorization_pending as a legitimate state rather than a failure, which is the pattern everything asynchronous still uses.

CIBA OpenID

The client names the user and the server pushes an approval prompt directly, with no redirect. The natural transport for approvals when the agent runs unattended.

Cross-Device Flows: Best Current Practice RFC 10027

Approving on device B what device A requested is also the shape of a good phishing attack. Read it before shipping either.

OAuth 2.0 for First-Party Applications WG draft

draft-ietf-oauth-first-party-apps

A native authorization API for apps the provider controls, so first-party clients don't need a browser redirect. Relevant when the agent genuinely is the user's own software.

Group five

Saying what is actually about to happen

The difference between a permission and an act: in the request, on the consent screen, in the token, in the log.

Rich Authorization Requests RFC 9396

Structured authorization_details in place of a scope string. Consent describes the operation, the token carries it, the resource enforces it exactly. Used in scenario 03.

RAR Metadata and Error Remediation WG draft

draft-ietf-oauth-rar-metadata-remediation

Lets a server advertise which authorization details types it supports and return structured errors a client can act on. What lets RAR be negotiated with a stranger instead of agreed bilaterally.

Step Up Authentication Challenge RFC 9470

A resource server rejects a request and says what it needs: fresher or stronger authentication. The precedent for letting the resource, not the client, set the bar.

Transaction Authorization Challenge Individual

draft-rosomakho-oauth-txn-challenge · June 2026

A resource issues a signed challenge describing one operation, a human approves it at the authorization server, and the resulting token proves the approval. Makes human-in-the-loop verifiable by the party that enforces it. Used in scenario 04.

Group six

Delegation, and getting across boundaries

Keeping "who asked, and who is acting for them" attached to a request as it travels.

Token Exchange RFC 8693

Trade one token for another, with act naming the actor operating on the subject's behalf and may_act constraining who may. The foundation under the next two entries.

Identity and Authorization Chaining Across Domains RFC queue

draft-ietf-oauth-identity-chaining · approved, awaiting an RFC number

Token exchange plus JWT bearer grants, composed so a client in one trust domain can get a token in another without either side accepting foreign tokens. Used in scenario 05.

Identity Assertion JWT Authorization Grant WG draft

draft-ietf-oauth-identity-assertion-authz-grant · "ID-JAG" / Cross-App Access

The enterprise profile of identity chaining: an IdP exchanges a user's identity for a short-lived, audience-bound grant, so one SaaS app reaches another's API under admin policy.

Transaction Tokens WG draft

draft-ietf-oauth-transaction-tokens

A short-lived, internally-scoped token carrying immutable call context through a fan-out, so the eleventh service knows who asked and what was authorized. Used in scenario 06.

Group seven

Ending access

The least glamorous group, and the one you'll care about most during an incident.

Token Revocation RFC 7009

An endpoint for killing a token or the grant behind it. Simple, ubiquitous, and covers only one authorization server.

Token Introspection RFC 7662

Ask the authorization server whether a token is still good and what it means. RFC 9701 adds a signed JWT response so the answer is verifiable.

Refresh Token and Authorization Expiration WG draft

draft-ietf-oauth-refresh-token-expiration

Lets the server say when the underlying authorization expires, not just the current token, so an unattended agent renews at a sensible moment instead of failing mid-task.

Shared Signals Framework, CAEP & RISC OpenID

Near-real-time notification that a session ended, a credential changed, risk was elevated or a grant was revoked. CAEP covers continuous access evaluation, RISC covers risk and incident signals. Cached authorization is not supposed to outlive the signal that killed it. The lag is deployment, not the spec.

Group eight

The ground rules

How to do all of the above without introducing something regrettable.

OAuth 2.1 WG draft

draft-ietf-oauth-v2-1

OAuth 2.0 and its extensions with the bad options removed: PKCE required, implicit and password grants gone, exact redirect URI matching. The baseline MCP builds on, and the right starting point for anything new.

OAuth 2.0 Security Best Current Practice RFC 9700

Fifteen years of attacks and their mitigations, in one document. An update is in progress in the working group.

OAuth 2.0 for Browser-Based Applications RFC 10017

How to handle tokens when part of your agent's surface is a web app. Mostly: don't keep them in the browser.

AI Agent Authentication and Authorization Individual

draft-klrc-aiagent-auth

An informational draft making the same argument from the other end. Read it for the parts this site treats lightly: identifying an individual running instance, monitoring and audit, and the policy it's all configured by.

MCP Authorization Protocol spec

Not an IETF document, but where these building blocks are being assembled in public: OAuth 2.1 resource servers, protected resource metadata, resource indicators, issuer validation, and client ID metadata documents as the preferred registration path.

Count them

Thirty-odd documents on this page. Two of them were written because of agents. The rest were already there, already deployed, already reviewed. That is the entire argument this site is making.