# OAuth 2.0: the new security best practices (RFC 9700)
Table of Contents
In January 2025 the IETF - the body that maintains Internet’s technical standards - published RFC 9700, titled “Best Current Practice for OAuth 2.0 Security”. The document gathers, in an official and updated form, the security rules recommended for anyone using OAuth 2.0, the mechanism behind the familiar “Sign in with Google” and behind much of the protected APIs on the web. It doesn’t introduce a new protocol: it tidies things up, updates the existing advice and marks some now-risky practices as things to avoid.
What OAuth 2.0 is, briefly
OAuth 2.0 is a standard for delegated authorization. Put simply: it lets an application get limited access to a service on behalf of a person, without that person having to hand their password over to the application. It’s what happens when a site offers “Sign in with Google” or “Connect your account”. The origin service verifies the identity and issues the application a token - a temporary pass that acts as an access permission, with precise limits on what it can do and for how long.
The benefit is clear. The password stays with the origin service, the application receives only the minimum it needs, and that permission can be revoked at any time. That’s exactly why OAuth 2.0 has become the backbone of logins and APIs across much of the web: from social networks to cloud platforms to integrations between business software.
Three terms are worth clarifying up front, as they’ll come back. An access token is the pass that grants access to a resource. An authorization code is an intermediate step: a short code the application then exchanges for the actual token. A redirect URI is the address the service sends the user back to after consent, and where it delivers that code.
Why an updated reference matters
OAuth 2.0 was published in 2012 (RFC 6749). It has been adopted almost everywhere since, and with adoption at scale came attacks and pitfalls that weren’t clear at first. The original security rules turned out to be too generic in some places and outdated in others.
RFC 9700 exists for this reason. It’s a Best Current Practice - BCP for short, numbered 240 - meaning a document that doesn’t describe a new technical standard but collects the best practice the community recommends at a given moment. Concretely, it updates and extends three earlier documents: the base OAuth 2.0 specification (RFC 6749), the rules on using “bearer” tokens (RFC 6750) and the older threat model (RFC 6819). The stated aim is to fold in the experience gathered in the field and to cover new threats that arose from the protocol’s ever-wider use.
An important point: this isn’t a draft or a proposal. It’s a document published in January 2025, at the level of official “current practice”. The authors are Torsten Lodderstedt (SPRIND), John Bradley (Yubico), Andrey Labunets and Daniel Fett (Authlete), well-known names in the digital identity space.
The main recommendations
The text is long and detailed, but a handful of points capture the direction well.
PKCE for public applications. PKCE is a mechanism that ties the initial request to the final code exchange, so that an intercepted code isn’t enough on its own to obtain the token. The RFC makes it mandatory for “public” clients - mobile apps and applications running in the browser, which can’t safely keep a secret - and recommends it for the others too. Authorization servers must support it and verify it, so an attacker can’t work around it.
Exact matching of redirect URIs. The server must compare the return address against the ones registered in advance character by character, with no shortcuts. It’s a defense against hijacking the authorization code toward a site the attacker controls. The one practical exception concerns native apps on “localhost”, where the port number may vary.
Tokens bound to who uses them. A classic risk is token theft: whoever steals it can reuse it. The RFC recommends sender-constrained tokens - tokens tied to the legitimate client - via mutual TLS (RFC 8705) or DPoP (RFC 9449). In practice the token alone isn’t enough: proof of being the original holder is also required.
Refresh token protection. A refresh token is a longer-lived pass used to obtain new access tokens without logging in again. For public applications the RFC asks that it too be bound to the client, or that it be rotated - replaced on each use - so that a stolen token soon stops working.
Defense against “mix-up” attacks. When an application talks to several authorization servers, an attacker can try to confuse the responses between one and another. The required countermeasure is to clearly identify who issued the response (through the iss parameter) or to use distinct return addresses for each server.
To these are added two ground rules: authorization responses must never travel over unencrypted connections, and it’s worth relying on the authorization server’s metadata to enable security options automatically, which reduces configuration mistakes.
What is discouraged or removed
Part of RFC 9700’s value lies in what it takes away.
The implicit grant is dropped - an old flow that delivered the access token directly in the browser response: convenient once, but exposed to token leakage and reuse. The authorization code flow with PKCE should be used in its place.
The resource owner password credentials flow is excluded entirely - the one where the user types their password directly into the application, which then passes it on to the service. It defeats the very point of OAuth (keeping the password out of the application’s hands) and is incompatible with multi-factor authentication. The RFC states plainly that it must not be used.
Why it matters for those exposing logins and APIs
For anyone running a service with social login or protected APIs, RFC 9700 is the reference to align with. It doesn’t demand rewriting everything tomorrow, but it says clearly what counts as secure today and what doesn’t.
It works as a practical checklist: confirm that PKCE is in place, that redirect URIs are matched exactly, that the implicit and password flows have been retired, that refresh tokens are rotated or bound. Developers building integrations now have a single, citable document to point to in technical decisions and security reviews. And anyone relying on third-party libraries or identity providers can use it as a yardstick to check whether they follow the updated practice.
The underlying message is simple: OAuth 2.0 remains valid, but the secure way to use it has been refined by experience. Having that way written down, in an official document, helps cut the most common mistakes.
