OAuth 2.1: The Future of API Security
A presentation at phpday 2025 in in Verona, VR, Italy by Rob Allen
OAuth 2.1 The Future of API Security Rob Allen, May 2025
OAuth is the standard for securing access to APIs Rob Allen ~ akrabat.com
OAuth 2.0 A Refresher Rob Allen ~ akrabat.com
OAuth 2.0 Roles • • • • Resource Owner (The User) Resource Server (The API) Client (The application that uses the API) Authorization Server (OAuth server) Rob Allen ~ akrabat.com
OAuth 2.0 Protocol Flows • • • • Resource Owner Password Credentials Authorization Code Implict Client Credentials Rob Allen ~ akrabat.com
Password Credentials Flow For logging into 1st party apps Rob Allen ~ akrabat.com
Password Credentials Flow Rob Allen ~ akrabat.com
Password Credentials Flow Rob Allen ~ akrabat.com
Password Credentials Flow Rob Allen ~ akrabat.com
Password Credentials Flow Rob Allen ~ akrabat.com
Authorization Code Flow For logging into 3rd party websites Rob Allen ~ akrabat.com
Authorization Code Flow Rob Allen ~ akrabat.com
Authorization Code Flow Rob Allen ~ akrabat.com
Authorization Code Flow Rob Allen ~ akrabat.com
Authorization Code Flow Rob Allen ~ akrabat.com
Authorization Code Flow Rob Allen ~ akrabat.com
Authorization Code Flow Rob Allen ~ akrabat.com
Authorization Code Flow Rob Allen ~ akrabat.com
Authorization Code Flow Rob Allen ~ akrabat.com
Authorization Code Flow Rob Allen ~ akrabat.com
Implicit Flow For logging into 3rd party apps and web SPAs Rob Allen ~ akrabat.com
Implict Flow Rob Allen ~ akrabat.com
Implict Flow Rob Allen ~ akrabat.com
Implict Flow Rob Allen ~ akrabat.com
Implict Flow Rob Allen ~ akrabat.com
Implict Flow Rob Allen ~ akrabat.com
Implict Flow Rob Allen ~ akrabat.com
Implict Flow Rob Allen ~ akrabat.com
Client Credentials Flow For jobs that don’t need user permission Rob Allen ~ akrabat.com
Client Credentials Flow Rob Allen ~ akrabat.com
Client Credentials Flow Rob Allen ~ akrabat.com
Client Credentials Flow Rob Allen ~ akrabat.com
OAuth 2.0 Refresh token • Allows the client to gain a new access token • Refresh tokens need to be kept secure • Authorization server can choose not to issue Rob Allen ~ akrabat.com
OAuth 2.0 Since 2012 Rob Allen ~ akrabat.com
The OAuth 2.0 Framework in 2012 Rob Allen ~ akrabat.com
The OAuth 2.0 Framework Today Rob Allen ~ akrabat.com
Key extensions since 2012 • RFC 7636: Authorization Code without a client secret (PKCE) • RFC 8628: Device Authorization grant for devices Rob Allen ~ akrabat.com
PKCE • First created for mobile, but useful for all public clients • Protects the authorization code in the redirect • We know that the right client is converting the code to a token Rob Allen ~ akrabat.com
PKCE workflow Rob Allen ~ akrabat.com
PKCE workflow Rob Allen ~ akrabat.com
PKCE workflow Rob Allen ~ akrabat.com
PKCE workflow Rob Allen ~ akrabat.com
PKCE workflow Rob Allen ~ akrabat.com
Device Authorization Flow For apps with no browser (or keyboard) Rob Allen ~ akrabat.com
Device Authorization Flow Rob Allen ~ akrabat.com
Device Authorization Flow Rob Allen ~ akrabat.com
Device Authorization Flow Rob Allen ~ akrabat.com
Device Authorization Flow Rob Allen ~ akrabat.com
Best Practices since 2012 • RFC 7900: Best Current Practice for OAuth 2.0 Security • RFC 8653: OAuth 2.0 for Native Apps • OAUTH-WG: OAuth 2.0 for Browser Apps Rob Allen ~ akrabat.com
Best Current Practice • Always use PKCE with Authorization Code Rob Allen ~ akrabat.com
Best Current Practice • Always use PKCE with Authorization Code • Don’t use Implicit flow; use Authorization Code (with PCKE) Rob Allen ~ akrabat.com
Best Current Practice • Always use PKCE with Authorization Code • Don’t use Implicit flow; use Authorization Code (with PCKE) • Don’t use Password flow; use Authorization Code (with PCKE) Rob Allen ~ akrabat.com
Best Current Practice • • • • Always use PKCE with Authorization Code Don’t use Implicit flow; use Authorization Code (with PCKE) Don’t use Password flow; use Authorization Code (with PCKE) Use exact string matching for redirect URIs Rob Allen ~ akrabat.com
Best Current Practice • • • • • Always use PKCE with Authorization Code Don’t use Implicit flow; use Authorization Code (with PCKE) Don’t use Password flow; use Authorization Code (with PCKE) Use exact string matching for redirect URIs No access tokens in query strings Rob Allen ~ akrabat.com
Best Current Practice • • • • • • Always use PKCE with Authorization Code Don’t use Implicit flow; use Authorization Code (with PCKE) Don’t use Password flow; use Authorization Code (with PCKE) Use exact string matching for redirect URIs No access tokens in query strings Refresh tokens must be sender constrained or one-time use Rob Allen ~ akrabat.com
Best Current Practice • • • • • • • Always use PKCE with Authorization Code Don’t use Implicit flow; use Authorization Code (with PCKE) Don’t use Password flow; use Authorization Code (with PCKE) Use exact string matching for redirect URIs No access tokens in query strings Refresh tokens must be sender constrained or one-time use … plus other good implementation information! Rob Allen ~ akrabat.com
OAuth 2.1 Rob Allen ~ akrabat.com
My main goal with OAuth 2.1 is to capture the current best practices in OAuth 2.0 as well as its well-established extensions under a single name. Aaron Parecki Rob Allen ~ akrabat.com
Key Objectives of OAuth 2.1 • Not a new protocol Rob Allen ~ akrabat.com
Key Objectives of OAuth 2.1 • Not a new protocol • Simplifies the specification Rob Allen ~ akrabat.com
Key Objectives of OAuth 2.1 • Not a new protocol • Simplifies the specification • Incorporation of Best Current Practices Rob Allen ~ akrabat.com
OAuth 2.1 Flows • Authorization Code + PKCE • Device Authorization • Client Credentials Rob Allen ~ akrabat.com
Tokens • Transfer only by HTTP header or POST form body • Require sender contraints or one-time use refresh tokens • Refined token management (shorter lifetimes, rotation policies) Rob Allen ~ akrabat.com
Other things • • • • Redirect URIs must be exact matches State parameter is now mandatory for CSRF protection Confidential client now means a client that has credentials Otherwise it’s public Rob Allen ~ akrabat.com
Going forwards Rob Allen ~ akrabat.com
Migrating to 2.1 Rob Allen ~ akrabat.com
Migrating to 2.1 • Review current implementation Rob Allen ~ akrabat.com
Migrating to 2.1 • Review current implementation • Adopt Authorization Code flow with PKCE Rob Allen ~ akrabat.com
Migrating to 2.1 • Review current implementation • Adopt Authorization Code flow with PKCE • Remove deprecated flows Rob Allen ~ akrabat.com
Migrating to 2.1 • • • • Review current implementation Adopt Authorization Code flow with PKCE Remove deprecated flows Secure redirect Uris Rob Allen ~ akrabat.com
Migrating to 2.1 • • • • • Review current implementation Adopt Authorization Code flow with PKCE Remove deprecated flows Secure redirect Uris Review and implement the Best Current Practices Rob Allen ~ akrabat.com
Other relatively new OAuth features Rob Allen ~ akrabat.com
Other relatively new OAuth features • Demonstrating Proof of Possession (RFC 9449) • Mutual TLS (RFC 8705) Rob Allen ~ akrabat.com
Other relatively new OAuth features • • • • Demonstrating Proof of Possession (RFC 9449) Mutual TLS (RFC 8705) JWT Profile for Access Tokens (RFC 9068) JWT-Secured Authorization Requests (RFC 9101) Rob Allen ~ akrabat.com
Other relatively new OAuth features • • • • • • Demonstrating Proof of Possession (RFC 9449) Mutual TLS (RFC 8705) JWT Profile for Access Tokens (RFC 9068) JWT-Secured Authorization Requests (RFC 9101) Rich Authorization Requests (RFC 9396) Pushed Authorization Requests (RFC 9126) Rob Allen ~ akrabat.com
Rob Allen ~ akrabat.com
Thank you! slides: https://akrabat.com/7337 q&a and feedback: https://grusp.org/agenda Rob Allen ~ akrabat.com
OAuth 2 is the gold standard for authentication in APIs and is currently being updated to version 2.1. In this talk we’ll dive into how it works and what’s different from OAuth 2.0. OAuth 2.1 consolidates and simplifies OAuth 2.0 along with bringing the best practices that have evolved since 2.0’s release into the main standard. I’ll discuss how the Authorization grant type has evolved with PKCE to make it the best for nearly all clients, and also cover the best practices to use today in order to secure your API. By the end of this session, you’ll be well prepared for the future of API security.
