IETF · January 2025
RFC 9700 (BCP 240)
T. Lodderstedt, J. Bradley, A. Labunets, D. Fett
Agent runtimes leak tokens through logs, traces, and model context. RFC 9700's push toward sender-constrained, audience-restricted, short-lived tokens is the cheapest security upgrade you can make before AAuth or WIMSE.
At a glance
Actors
01
RFC 6749's original threat model did not include mix-up, authorization-code injection at confidential clients, or token leakage via URLs at internet scale. RFC 9700 (BCP 240, January 2025) is the update that makes 2.0 safe enough to build agents on.
Agent runtimes add leakage paths (prompts, traces, shared tool hosts) that make 9700's push toward sender-constrained, audience-restricted, short-lived tokens the cheapest upgrade before AAuth or WIMSE.
02
Assumes attackers on the network, in the browser, and who can steal tokens from clients. Authorization servers, clients, and resource servers all have MUST/SHOULD mitigations. An agent host is a client in this document — usually a confidential web app or a public native/browser app, not a new role.
03
Not a new protocol. It mandates authorization code + PKCE, exact redirect matching, sender-constrained or rotating refresh tokens for public clients, audience-restricted access tokens when multiple resources exist, and deprecates implicit and password grants. Mix-up mitigation includes the iss authorization-response parameter (RFC 9207). Tokens must not be placed in URIs.
An update draft (draft-ietf-oauth-security-topics-update) was an active WG document in July 2026. Read RFC 9700 first; treat the update as pending deltas.
04
Flow 1
Register exact redirect URIs. Use HTTPS except native loopback.
Authorization code + PKCE S256. Include resource indicators if talking to a specific API.
Validate iss on the response against the AS you intended.
Token request on the back channel. Store tokens outside model context. Prefer DPoP or mTLS.
RS checks audience. No tokens in query strings.
05
Security profile sitting across client authentication and request authorization. It is why OAuth 2.1 exists. It is not an identity protocol.
06
2.1 is this BCP consolidated into the core document.
FAPI 2.0 Security Profile is explicitly built on RFC 9700 and then tightens further (PAR, confidential-only, sender-constrained access tokens).
Recommended sender-constraint mechanism when mTLS is impractical.
RFC 9207 is the concrete mix-up fix 9700 relies on.
07
The most common agent-SDK failure. If your library still offers implicit, it is not BCP-compliant.
9700 requires restricting tokens when multiple RSes exist. MCP makes this a MUST even if the AS currently ignores resource.
Public-client refresh tokens must be sender-constrained or one-time-use. A stolen refresh token is a standing session.
08
RFC 9700 (BCP 240), January 2025, T. Lodderstedt, J. Bradley, A. Labunets, D. Fett. Stable BCP. Ship it today. https://www.rfc-editor.org/rfc/rfc9700.html
An update draft (draft-ietf-oauth-security-topics-update) was an active WG document in July 2026. Read RFC 9700 first; treat the update as pending deltas. FAPI 2.0 Security Profile is explicitly built on this BCP.