Wiki · Concept · Last reviewed June 25, 2026

OAuth Security Best Current Practice

RFC 9700 is the IETF Best Current Practice that tightens OAuth 2.0 security around redirects, PKCE, token replay, refresh tokens, client authentication, and dynamic deployments.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: AI agents, authorization, OAuth, security BCP, PKCE, audit trails

Definition

OAuth Security Best Current Practice is the guidance standardized as RFC 9700, Best Current Practice for OAuth 2.0 Security. It was published by the IETF in January 2025 as BCP 240 and was authored by Torsten Lodderstedt, John Bradley, Andrii Labunets, and Daniel Fett. The RFC updates RFC 6749, RFC 6750, and RFC 6819.

RFC 9700 does not replace OAuth 2.0. It consolidates newer operational lessons, adds stricter requirements, updates the attacker model, and deprecates modes of operation the authors judge less secure or insecure. It is the reference page a security review should open when an OAuth deployment claims to be "modern."

For AI agents, the value is practical. Agent connectors, tool brokers, browser-based automations, and multi-tenant integrations often depend on OAuth, but a token-bearing agent is only as safe as the flow that created and constrained its tokens.

The page is about authorization security, not model capability. RFC 9700 does not prove that an AI agent, MCP server, connector, or browser automation is safe. It describes controls for reducing OAuth-specific failures such as code interception, redirect abuse, token replay, token overbreadth, mix-up attacks, and unsafe legacy grants.

Snapshot

Current Context

As of June 25, 2026, RFC 9700 is the stable IETF Best Current Practice for OAuth 2.0 security. OAuth 2.1 is still an Internet-Draft, not a final RFC; draft-ietf-oauth-v2-1-15, published in March 2026, says it consolidates OAuth 2.0 with later updates including RFC 9700 and OAuth 2.0 for Native Apps. That means production governance should cite RFC 9700 and the relevant companion RFCs directly rather than treating "OAuth 2.1" as a completed standard.

The IETF OAuth working group is also considering updates to the security topics guidance. The current update draft, draft-ietf-oauth-security-topics-update-02, describes itself as extending RFC 6749, RFC 6750, and RFC 9700 to cover new threats discovered after those documents. Because it remains a draft, it is useful current context but should not be cited as if it superseded RFC 9700.

Agent infrastructure has made the topic more immediate. The Model Context Protocol 2025-11-25 authorization specification frames protected MCP servers as OAuth 2.1 resource servers and MCP clients as OAuth clients, requires MCP servers to implement OAuth 2.0 Protected Resource Metadata, requires MCP clients to use that metadata for authorization-server discovery, and requires resource indicators for token requests. MCP's security guidance also forbids token passthrough. Those rules make RFC 9700-style controls part of the agent tool boundary, not only web-login hygiene.

How It Works

The RFC begins with redirect-based flows. Authorization servers must compare client redirect URIs by exact string matching, except for variable localhost ports used by native apps. Clients and authorization servers must not expose open redirectors that forward a browser to an arbitrary URI from a query parameter.

For authorization-code flows, public clients must use PKCE, and confidential clients are recommended to use it. Authorization servers must support PKCE, enforce the correct code_verifier when a challenge was sent, mitigate PKCE downgrade attacks, and provide a way to detect PKCE support. The RFC recommends publishing code_challenge_methods_supported in Authorization Server Metadata.

RFC 9700 says clients should not use the implicit grant or other response types that issue access tokens in the authorization response unless access-token injection and leakage vectors are mitigated. It says clients should instead use the authorization-code response type or another response type that returns access tokens from the token endpoint.

The token guidance is direct: access-token privileges should be restricted to the minimum required, access tokens should be audience-restricted to a specific resource server or small set of resource servers, and resource servers must refuse a token intended for another audience. Public-client refresh tokens must be sender-constrained or use refresh-token rotation.

Sender constraint can be implemented by mechanisms such as mutual TLS certificate-bound tokens under RFC 8705 or DPoP under RFC 9449. Audience restriction can be supported by OAuth Resource Indicators under RFC 8707. Authorization-server and protected-resource metadata under RFC 8414 and RFC 9728 make feature discovery and endpoint identity less ad hoc.

RFC 9700 also keeps old failure modes in scope: credential leakage through browser surfaces, insufficient redirection URI validation, mix-up attacks, authorization-code injection, access-token injection, cross-site request forgery, token replay, refresh-token compromise, client impersonation of the resource owner, clickjacking, and in-browser communication flaws.

Agent Context

Agent deployments make the RFC more important, not less. A human-facing app may fail at a redirect URI once; an agent connector can repeat the same unsafe pattern across calendars, drives, repositories, help desks, payment systems, and internal APIs. OAuth flaws become workflow flaws when a model-driven system can trigger them at scale.

Multi-provider agents also resemble the dynamic scenarios RFC 9700 names: the same client may interact with different authorization servers or tenants, and endpoint configuration may be discovered through metadata. In those settings, mix-up defenses matter. When a client can interact with more than one authorization server, the RFC requires a defense against mix-up attacks, preferably using issuer identification or a comparable issuer value.

MCP makes this concrete. A remote tool server can advertise protected-resource metadata, an agent host can discover authorization-server metadata, and the client can request a token for a specific MCP server by using a resource indicator. If those records are missing, an agent may hold a broadly useful token while model-visible context decides where to send it.

The lesson is not that OAuth makes agent action safe. The lesson is that agent authority should pass through flows with exact redirects, PKCE, issuer-aware configuration, protected-resource metadata, audience checks, sender constraints where appropriate, refresh-token protection, revocation paths, and agent-level audit trails.

Governance and Safety

RFC 9700 says the resource owner password credentials grant must not be used, because it exposes the resource owner's credentials to the client and trains users to enter credentials outside the authorization server. It also recommends client authentication where feasible and recommends asymmetric client authentication such as mutual TLS or signed JWTs.

For governance, the useful artifact is a control matrix. Each OAuth connector should record whether it uses exact redirect matching, PKCE, issuer mix-up defense, sender-constrained access tokens, audience restriction, refresh-token rotation or sender constraint, asymmetric client authentication, authorization-server metadata, protected-resource metadata, token revocation, and resource-server audience validation.

Audit trails should preserve the authorization server, issuer, client ID, redirect URI, PKCE method, granted scopes, resource indicators or audience values, token class, refresh-token protection, client authentication method, resource server, and agent run. Logs should not store authorization codes, access tokens, refresh tokens, client secrets, private keys, or full signed assertions.

For AI governance, OAuth review belongs with AI Agent Identity, AI Agent Sandboxing, AI Agent Observability, and AI Vulnerability Disclosure. OAuth answers who can obtain and present a token; those adjacent controls answer what the agent can touch, what it actually did, and how failures are reported.

Procurement should treat OAuth posture as deployment evidence. A vendor saying "uses OAuth" is not enough. The relevant question is whether the deployed connector follows RFC 9700 controls, whether the resource server validates audience, whether refresh tokens are protected, whether scopes are narrow, and whether the organization can revoke, audit, and rotate the grant after an incident.

Minimum Evidence Record

A governance-grade OAuth record for an agent connector should make the authorization boundary reviewable without leaking the credentials themselves.

Defense Pattern

Source Discipline

Claims about OAuth security posture should identify the RFC 9700 control being discussed and the deployment role it applies to: client, authorization server, resource server, or reverse proxy. Do not collapse RFC 9700 into PKCE alone, sender-constrained tokens alone, generic "zero trust," or a promise that agent behavior is safe.

Use exact source labels. RFC 9700 is a Best Current Practice. OAuth 2.1 is still an Internet-Draft as of this review date. MCP authorization is a protocol specification that uses OAuth concepts for MCP clients and servers. A vendor connector page describes one implementation. These sources are related but not interchangeable.

For security claims, name the artifact and date: RFC number or draft version, authorization-server metadata, protected-resource metadata, client registration, redirect URI, token policy, resource indicator, sender-constraint method, and test date. A vague statement that a connector is "OAuth-secured" is not evidence.

Spiralist Reading

Spiralism reads RFC 9700 as institutional memory hardened into procedure. The standard is not glamorous. It says: stop accepting vague doors, stop leaking tokens through browser surfaces, stop letting old grants carry new power, and make each credential answer where, who, and for what.

For agents, that discipline is a spiritual technology of limits. It does not make the machine wise. It makes authority harder to smuggle.

Open Questions

Sources

Return to Wiki