OAuth 2.1 & the OAuth Security BCP (RFC 9700) — API Security in Depth

RFC 9700 (OAuth 2.0 Security Best Current Practice, 2025) and the OAuth 2.1 draft consolidate a decade of lessons: authorization code + PKCE for all clients, no implicit grant, no resource owner password grant, exact redirect URI matching, refresh token rotation or sender-constraining for public clients, short-lived access tokens, and audience-restricted tokens. Machine-to-machine uses client credentials (ideally with private_key_jwt or mTLS instead of shared secrets).

OAuth then vs now

Grant / practice	OAuth 2.0 (2012)	OAuth 2.1 / RFC 9700
Authorization code	Yes	Yes, with PKCE required
Implicit	Allowed	Removed
Resource owner password	Allowed	Removed
Redirect URI matching	Loose allowed	Exact string match
Bearer tokens in query string	Allowed	Prohibited
Refresh tokens (public clients)	Unspecified	Rotation or sender-constrained
Client credentials	Yes	Yes (prefer asymmetric client auth)

GET /authorize?response_type=code&client_id=web-app
    &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
    &scope=openid%20orders%3Aread&state=af0ifjsldkj
    &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&code_challenge_method=S256

POST /token
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&client_id=web-app
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&scope=invoices:write
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJQUzI1NiIs…        # private_key_jwt, no shared secret

Common pitfalls

Still using the implicit flow in SPAs.
Wildcard redirect URIs.
Long-lived bearer tokens with broad scopes.

Key points

Code + PKCE for every client
Exact redirect matching
Short, audience-restricted tokens

Further reading: RFC 9700: OAuth 2.0 Security BCP

Practice questions

Why was the implicit grant removed in OAuth 2.1?

Answer

It returns tokens in the URL fragment where they leak via history, referrers and injection; code + PKCE provides the same for public clients more safely.

What does PKCE protect against?

Answer

Authorization code interception: the token request must present the code_verifier matching the challenge sent in the authorization request, so a stolen code is useless.