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.
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.