OAuth 2 Essentials

OAuth 2 Essentials

Speakers: Torsten Lodderstedt, CTO, yes.com

Conference: LocoMocoSec

YouTube: https://www.youtube.com/watch?v=Xs8MdN8v7ZQ

Overview

In "OAuth 2 Essentials," Torsten Lodderstedt, CTO of yes.com and a veteran in identity and standardization, provides a practitioner's guide to navigating the often-complex world of OAuth 2.0. The talk addresses the challenge developers face in implementing OAuth 2 securely and efficiently, given the proliferation of related RFCs and best current practices. Lodderstedt distills the vast OAuth 2 ecosystem into five core "essentials" and introduces several advanced modules crucial for robust API security.

This presentation is highly relevant for anyone involved in building or securing modern applications and APIs. OAuth 2 is the de facto standard for delegated authorization, underpinning countless services from consumer applications to enterprise integrations. However, its flexibility and extensibility can lead to misconfigurations and security vulnerabilities if not implemented correctly. Lodderstedt's insights, drawn from decades of experience in both implementing and standardizing identity solutions, offer a clear roadmap for developers and security professionals to leverage OAuth 2 effectively, ensuring both robust security and a seamless user experience.

The talk emphasizes practical, battle-tested recommendations that align with the latest security guidelines and the upcoming OAuth 2.1 specification. By focusing on fundamental grant types, token management strategies, and secure configuration patterns, Lodderstedt equips the audience with the knowledge to build resilient authorization flows, reduce attack surfaces, and scale their API security infrastructure.

Background

▶ Watch: Introduction and speaker's OAuth background (0:00)

OAuth 2.0 was designed with a fundamental principle: to decouple service invocation and API authorization from the user's actual authentication. This is achieved through access tokens, temporary credentials issued by a trusted authorization server (AS). This architectural separation offers significant advantages. From a software perspective, it allows for the creation of APIs that are agnostic to different client channels (e.g., smartphones, TVs, batch jobs), as the authorization server handles the channel-specific authentication flows. This encapsulation simplifies API development, allowing applications to orchestrate access to various APIs using a single access token.

From a security standpoint, centralizing user credential and consent handling within the authorization server significantly reduces the attack surface for both the API and the client. The AS can leverage advanced, origin-bound credentials like FIDO keys and easily integrate third-party logins. For the user, this translates into a single sign-on experience across APIs, where they log in once, authorize access, and the client can subsequently use access tokens multiple times without repeated authentication.

Initially published in 2012, OAuth 2.0 started with a core specification defining how to obtain and use access tokens, complemented by an RFC on security threat models (RFC 68910, edited by Lodderstedt himself). However, over the years, the OAuth 2.0 universe expanded dramatically with numerous RFCs introducing new mechanisms for diverse device classes, use cases, and Best Current Practices (BCPs). This rapid growth, while enhancing flexibility, also led to significant complexity, making it challenging for developers to identify the essential components for secure and effective implementations. This talk aims to simplify this universe by highlighting the most critical aspects from a practitioner's perspective, specifically tailored for consumer-facing services and APIs.

Key Findings

▶ Watch: Essential #1: Authorization Code Grant for all applications (6:30)

Torsten Lodderstedt identifies five essential components of OAuth 2.0 that form the foundation of secure and versatile implementations, particularly for consumer-facing services. He then expands on these with additional advanced modules for even higher security requirements.

The five core essentials are:

1. Authorization Code Grant: The fundamental and most secure grant type for any application requiring user interaction. It is versatile, supporting web, native, and single-page applications (SPAs).
2. Refresh Tokens: Crucial for managing long-term connections and improving user experience by enabling clients to obtain new, short-lived access tokens without re-authenticating the user. This also enhances security and simplifies token revocation.
3. JWT-based Access Tokens: Leveraging JSON Web Tokens (JWTs) for access tokens provides significant performance and scalability benefits by embedding all necessary authorization data directly within the token, eliminating the need for constant callbacks to the authorization server.
4. Client Credentials Grant: The recommended grant type for service-to-service interactions and batch processes where a client acts on its own behalf, offering dynamic and fine-grained permission management.
5. Server Metadata: A small but highly beneficial mechanism that allows clients to automatically discover an authorization server's endpoints and capabilities, streamlining configuration and enhancing security by preventing misconfigurations or phishing attempts.

Beyond these essentials, Lodderstedt highlights several advanced modules that significantly bolster security for higher-assurance scenarios:

• Mutual TLS for OAuth (RFC 8705): Uses X.509 certificates for robust client authentication and token binding.
• Pushed Authorization Requests (PAR): Improves security and supports large authorization payloads by allowing clients to send request parameters directly to the AS backend.
• Rich Authorization Requests (RAR): Enables the expression of complex, fine-grained authorization policies beyond simple scopes.
• FAPI 2.0 Secure Profile: A comprehensive security profile maintained by the OpenID Foundation for financial-grade APIs, incorporating many of these advanced features.

Technical Deep Dive

▶ Watch: Essential #3: JWT-based Access Tokens for performance (20:00)

The core of Lodderstedt's presentation lies in the detailed explanation and justification of his OAuth 2 essentials.

Authorization Code Grant

The Authorization Code Grant is presented as the most versatile and secure method for user-facing applications. The flow begins with the client redirecting the user agent (browser) to the authorization server (AS). The AS authenticates the user and, if required, obtains user consent for the requested access. Upon consent, the user agent is redirected back to the client with a temporary, one-time use credential called the authorization code. The client then, in a backend interaction, exchanges this code with the AS for an access token, which it subsequently uses to invoke protected APIs.

This grant type is highly adaptable:

• Web applications: The original use case, perfectly suited for server-side applications.
• Native applications: Can implement an "app-to-app redirect" for an optimized, native user experience, as seen in open banking.
• Single-Page Applications (SPAs): Can also use the authorization code flow, although it requires activating CORS on the AS and often necessitates moving the OAuth client code to a backend component to maintain confidentiality, especially for confidential clients that hold secrets.

Recent security enhancements, particularly from the OAuth Security Guidelines and the upcoming OAuth 2.1, have further hardened this flow. Key requirements include:

• Exact redirect URI matching: To prevent code leakage to malicious endpoints.
• Proof Key for Code Exchange (PKCE): A temporary, transaction-specific secret generated by the client, preventing intercepted authorization codes from being replayed on a different device.
• Mix-up prevention: For clients interacting with multiple authorization servers, this involves using distinct redirect URIs per AS or leveraging the new issuer response parameter to ensure tokens are used with the correct AS.

Refresh Tokens

Lodderstedt champions refresh tokens as the most underrated feature of OAuth 2. They solve the dilemma between long-lived access tokens (which can become stale or difficult to revoke) and frequent re-authorization (which provides a poor user experience). The strategy is to use short-lived access tokens (typically 5-20 minutes lifetime) in conjunction with refresh tokens.

After the initial authorization code flow, the AS issues both an access token and a refresh token. When the access token expires (signaled by an HTTP 401 response from the resource server), the client uses the refresh token in a backend request to the AS to obtain a new access token, and optionally, a new refresh token. This transparent process avoids user re-authentication, greatly improving UX.

Security benefits of refresh tokens are substantial:

• Simplified revocation: Revoking a refresh token immediately invalidates future access token requests. Given short-lived access tokens, the window of vulnerability after revocation is minimal (e.g., 5 minutes). This is far simpler than propagating access token revocation across all resource servers.
• Enhanced protection: Refresh tokens, exchanged over a TLS-protected backend channel, are inherently better protected than other OAuth parameters.
• Refresh token rotation: For public clients or scenarios requiring higher assurance, the AS can issue a new refresh token with every new access token. This "one-time use" pattern allows the AS to detect replay attacks (e.g., if an old, used refresh token is presented) and kill the entire grant, mitigating the impact of a stolen refresh token.
• Multi-service environments: Refresh tokens can be associated with a combined grant, allowing the AS to mint audience-restricted access tokens for different APIs from a single refresh token, enhancing the principle of least privilege.

JWT-based Access Tokens

The recommendation for access tokens is to use JSON Web Tokens (JWTs). JWTs are an IETF standard for representing claims as a digitally signed and optionally encrypted JSON object. When used as access tokens, JWTs contain all the necessary data for API authorization (e.g., user ID, scopes, client ID).

The primary advantages of JWT-based access tokens are:

• Performance: Since all authorization data is self-contained within the token, resource servers do not need to call back to the AS for every API invocation. They simply verify the token's signature and extract claims, which is incredibly fast and can be done in memory.
• Scalability: This eliminates the need for distributed caches or constant AS callbacks, allowing APIs to scale independently of the AS.
• Standards-based: JWTs are a widely adopted standard, facilitating interoperability and leveraging existing libraries. The "JSON Web Token Profile for OAuth Access Tokens" RFC is a recommended read.

While JWTs are excellent for most use cases, Lodderstedt acknowledges their limitation in scenarios requiring instant revocation, such as payment or electronic signing, where alternative token formats or immediate AS callbacks might be necessary. However, for the vast majority of applications, short-lived JWTs combined with refresh tokens offer the optimal balance of security, performance, and user experience.

Client Credentials Grant

For service-to-service interactions or batch processes where a client acts independently of a user, the Client Credentials Grant is the recommended approach. In this flow, the client authenticates directly with the AS (typically using a client secret or, preferably, a certificate) and obtains an access token. This token is then used to access protected APIs.

The key question is why use access tokens here, instead of direct client authentication with a certificate? The answer lies in dynamic and fine-grained permission management. The AS acts as a central policy enforcement point, allowing administrators to easily change a client's permissions without reconfiguring every API. New access tokens reflecting these updated policies are then issued. This also offers better performance for authorization decisions compared to querying a directory for permissions based on a certificate. Lodderstedt strongly recommends using certificates for client authentication with this grant type, rather than client secrets, for enhanced security.

Server Metadata

The fifth essential is OAuth 2.0 Authorization Server Metadata (RFC 8414). This small but impactful specification allows clients to automatically discover an AS's configuration details. Instead of manually configuring various endpoints (authorization, token, revocation, etc.), a client needs only the issuer URL (e.g., https://as.example.com/.well-known/oauth-authorization-server). By querying this well-known endpoint, the client can retrieve all necessary metadata, including endpoint URLs, supported scopes, and response types.

Benefits include:

• Efficiency: Simplifies client configuration, especially when integrating with multiple ASs.
• Flexibility: The AS can change its endpoint URLs without requiring client-side configuration updates.
• Security: It establishes a strong, verifiable link between the issuer URL and the configuration data, significantly reducing the risk of phishing attacks where a malicious actor might provide fake endpoint URLs via email. Most modern OAuth libraries support this automatic configuration.

Beyond the Essentials

Lodderstedt also introduces advanced modules for higher security contexts:

• Mutual TLS for OAuth (RFC 8705): This mechanism binds access and refresh tokens to the client's X.509 certificate. It provides stronger client authentication than client secrets and cryptographically ties the token to a specific client instance, preventing token replay. It can even be used with self-signed certificates, reducing the overhead of managing a full PKI.
• Pushed Authorization Requests (PAR): Instead of sending all authorization request parameters via the browser (which can be long and susceptible to leakage), PAR allows the client to send these parameters directly to the AS over a backend channel. The AS returns a request URI, which the client then passes to the browser. This improves security by authenticating the client before user interaction, protecting request parameters' integrity and confidentiality, and supporting large, complex authorization payloads.
• Rich Authorization Requests (RAR): An extension to OAuth 2.0 that allows for expressing more complex and granular authorization requests than simple scopes. For example, it can detail the specific amount, currency, and recipient for a payment authorization. This uses a JSON-based representation to provide richer context for user consent.
• FAPI 2.0 Secure Profile: The Financial Grade API (FAPI) working group at the OpenID Foundation maintains a security profile specifically designed for high-security APIs, such as those in open banking. FAPI 2.0 includes many of the advanced features like PAR, RAR, and Mutual TLS, providing a robust framework for critical applications.

Demo / Proof of Concept

▶ Watch: Essential #5: Server Metadata for secure client configuration (24:00)

The talk "OAuth 2 Essentials" by Torsten Lodderstedt is a conceptual and architectural discussion focused on best practices and design principles. It does not include a live demonstration or a proof of concept of any specific implementation. The content is delivered as a technical overview and set of recommendations based on the speaker's extensive experience in the field.

Defensive Implications

▶ Watch: Q&A: Protecting refresh tokens from interception (32:00)

Organizations implementing or securing APIs with OAuth 2.0 should adopt the following defensive strategies based on Lodderstedt's recommendations:

1. Prioritize Authorization Code Grant with PKCE: For any application involving user interaction (web, native, SPA), the Authorization Code Grant is the most secure foundation. Always implement PKCE (Proof Key for Code Exchange) to mitigate authorization code interception attacks and enforce exact redirect URI matching to prevent code leakage.
2. Embrace Short-Lived JWTs with Refresh Tokens: Combine short-lived, JWT-based access tokens (e.g., 5-20 minutes lifetime) with refresh tokens to achieve an optimal balance of user experience, performance, and security. Implement refresh token rotation to detect and prevent replay attacks on stolen refresh tokens. This significantly simplifies token revocation compared to invalidating distributed access tokens.
3. Secure Service-to-Service Communication with Client Credentials: For backend services or batch jobs acting independently, use the Client Credentials Grant. Crucially, authenticate clients using X.509 certificates instead of shared secrets to enhance security and enable dynamic, fine-grained permission management through the authorization server.
4. Leverage Server Metadata for Secure Configuration: Configure clients to automatically discover authorization server endpoints using the OAuth 2.0 Authorization Server Metadata endpoint (/.well-known/oauth-authorization-server). This reduces manual configuration errors, allows the AS to evolve its infrastructure seamlessly, and significantly lowers the risk of phishing attacks targeting endpoint configuration.
5. Explore Advanced Security Modules for High-Assurance APIs: For applications requiring higher security, such as financial services or sensitive data protection, investigate and implement:

• Mutual TLS for OAuth (RFC 8705): Bind access and refresh tokens to client certificates for strong client authentication and token integrity.
• Pushed Authorization Requests (PAR): Enhance the security of authorization requests by sending parameters over a backend channel, protecting them from browser-based interception and supporting complex policy payloads.
• Rich Authorization Requests (RAR): Implement granular, context-aware authorization policies that go beyond simple scopes, providing users with more transparent and specific consent requests.
• Adopt FAPI 2.0 Secure Profile: If operating in a highly regulated or sensitive domain, align implementations with the Financial Grade API (FAPI) 2.0 Secure Profile for a comprehensive, battle-tested security framework.

1. Protect Authorization Server Private Keys: As JWT-based access tokens rely on the AS's signing key, ensure these private keys are stored in highly secure environments, such as Hardware Security Modules (HSMs) or dedicated key vaults, to prevent token fabrication by attackers.

By systematically applying these defensive strategies, organizations can build robust, scalable, and secure OAuth 2.0 implementations that withstand modern threats and provide a reliable authorization layer for their APIs.

Key Takeaways

• Authorization Code Grant with PKCE is Foundational: For all user-facing applications, the Authorization Code Grant combined with PKCE (Proof Key for Code Exchange) and exact redirect URI matching is the most versatile and secure method for delegated authorization.
• Refresh Tokens Enable Secure, Seamless UX: Use refresh tokens in conjunction with short-lived, JWT-based access tokens to provide a superior user experience, improve performance, and simplify token revocation, especially when implementing refresh token rotation.
• JWTs Drive Performance and Scalability: JSON Web Tokens (JWTs) for access tokens offer significant performance benefits by embedding authorization data, eliminating the need for constant AS callbacks, and enhancing API scalability.
• Client Credentials Grant for Service-to-Service Security: For clients acting on their own behalf (e.g., batch jobs), the Client Credentials Grant with certificate-based client authentication provides dynamic, fine-grained permission management and robust security.
• Server Metadata Streamlines and Secures Client Configuration: Leverage OAuth 2.0 Authorization Server Metadata for automatic client configuration, reducing errors, increasing efficiency, and mitigating phishing risks associated with manual endpoint setup.
• Advanced Modules for Elevated Security Needs: For high-assurance scenarios, explore and implement Mutual TLS for OAuth (RFC 8705), Pushed Authorization Requests (PAR), Rich Authorization Requests (RAR), and consider adopting the FAPI 2.0 Secure Profile.

About the Speaker(s)

Torsten Lodderstedt is the CTO of yes.com, an open banking scheme that empowers financial institutions to act as identity providers and deliver identity data, electronic signing, and payment capabilities via APIs. With over 30 years of experience in the identity space, Lodderstedt is a respected identity practitioner and a key figure in standardization efforts.

Prior to his role at yes.com, which he joined in 2017, he worked in the consumer identity team at Deutsche Telekom in Germany, where he utilized OAuth to protect APIs for entertainment, communication, and cloud services. His deep involvement in OAuth standardization began in early 2010 with the development of OAuth 2.0. Notably, he was the editor of RFC 68910, the OAuth security threat model and considerations, which laid the groundwork for the core specification's security considerations. He continues to contribute to various OAuth specifications, including the new OAuth security guidelines and OAuth 2.1.