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

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.

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.

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

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, and authorization server metadata.

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, and agent run. Logs should not store authorization codes, access tokens, refresh tokens, client secrets, private keys, or full signed assertions.

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.

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