Breaking Tokens: Modern Attacks on OAuth, OIDC, and JWT Auth Flows

Breaking Tokens: Modern Attacks on OAuth, OIDC, and JWT Auth Flows

Speakers: Bhaumik Shah

Conference: BSides SF

YouTube: https://www.youtube.com/watch?v=B7-q41BBK5o

Overview

In the contemporary landscape of web and mobile applications, OAuth, OpenID Connect (OIDC), and JSON Web Tokens (JWTs) have become the de facto standards for authentication and authorization. While these protocols offer robust frameworks for secure identity management, their complex implementations and the distributed nature of modern microservice architectures introduce new attack vectors. Bhaumik Shah's talk, "Breaking Tokens: Modern Attacks on OAuth, OIDC, and JWT Auth Flows," meticulously dissects three critical vulnerabilities that can lead to significant breaches, even in systems employing multi-factor authentication (MFA).

Shah, a seasoned security expert with extensive experience in identity systems, cloud, and infrastructure, underscores the critical importance of understanding these attacks by likening a token to a digital currency: "whoever has the token or whoever has the currency can spend it." This analogy highlights the potential for severe consequences if tokens are forged, replayed, or mishandled. The talk serves as an urgent call to developers and security professionals to re-evaluate their token validation logic, scope definitions, and identity provider configurations to fortify their systems against sophisticated token-based exploits.

The session delves into real-world examples, including the Salesforce OAuth token breach and the Microsoft Storm-2372 attack, demonstrating how subtle misconfigurations or overlooked validation steps can escalate into widespread access to sensitive customer environments and internal systems. By presenting detailed technical breakdowns and proof-of-concept demonstrations, Shah provides actionable insights into preventing such breaches, advocating for more granular control over token lifecycles and a more robust approach to federated identity management.

Background

▶ Watch: Real-world Salesforce OAuth token breach example (0:50)

The modern application landscape has fundamentally shifted away from monolithic, centralized authorization servers. Today, security decisions are no longer confined to a single point but are distributed across a multitude of backend APIs, microservices, and mobile applications. This distributed model, while offering scalability and flexibility, introduces significant complexity to identity management. In a typical OAuth/OIDC flow, a client application requests authentication from an Identity Provider (IDP) (e.g., Google, Okta, Auth0, Azure). Upon successful user validation, the IDP issues an OAuth token or an ID token (often a JWT) to the client. This token is then passed to backend services, which are responsible for validating it and granting access to specific resources.

The core challenge in this distributed environment lies in the validation process. Every system that receives a token must independently verify its authenticity, integrity, scope, and the identity of the user it represents. This includes checking the token's signature, its validity period, whether it was issued to the correct user, and ensuring it hasn't been forged or tampered with. A single misstep in any of these validation points across the intricate web of microservices can compromise the entire identity system. This is a stark contrast to traditional systems where session information was often maintained and validated by a single, trusted authorization server. The talk emphasizes that "if even if one system does not make the right decision, the entire identity system collapses," highlighting the fragility inherent in widely distributed security decision-making.

The speaker introduces the concept of a token as "currency," stressing that possession of a valid token grants access, irrespective of how it was obtained. This underpins the severity of the attacks discussed, where attackers exploit weaknesses in how tokens are issued, validated, or scoped to gain unauthorized access. The evolution of applications to leverage multiple identity providers (federated identity) further complicates this, as applications must not only validate the token itself but also understand and trust the issuer, adding another layer of potential vulnerability.

Key Findings

▶ Watch: Understanding distributed security decisions in modern systems (3:40)

Bhaumik Shah's presentation unveils three critical classes of attacks targeting modern OAuth, OIDC, and JWT authentication flows, each exploiting distinct weaknesses in implementation and validation logic:

1. Breaking Microservices with Token Replay (Scope Confusion): This attack demonstrates how a broadly scoped token, intended for a public-facing service, can be replayed to access internal, undocumented microservices behind an API gateway. The core vulnerability lies in insufficient granular scoping of tokens and the gateway's failure to enforce strict access controls based on the token's intended use. Once a token passes the initial gateway validation, its broad permissions allow it to access any service it's presented to, leading to privilege escalation and unauthorized data access. The Salesforce OAuth token breach, which allowed attackers to access 7,000+ customer environments due to a widely scoped integration token, serves as a real-world example of this vulnerability.

1. Bearer Token Replay (MFA Bypass Post-Authentication): This scenario highlights the danger of bearer tokens that are not cryptographically bound to a specific device or session. Even when strong authentication mechanisms like MFA are used during the initial login, once a token is stolen (e.g., via phishing, local storage vulnerabilities), it can be replayed by an attacker from any location or device. The token itself becomes the sole key to access, bypassing subsequent MFA checks. The Microsoft Storm-2372 attack, where attackers used phishing to steal tokens and gain access despite MFA, is a prominent illustration. The finding emphasizes that MFA protects authentication, but not authorization once a bearer token is compromised.

1. Federated Identity Confusion (Issuer Trust Level Bypass): This complex attack targets applications that integrate with multiple identity providers (IDPs) without adequately differentiating their trust levels. An attacker can create an account with a low-trust internal IDP (which might allow self-registration, lack MFA, or skip email/domain verification) using an email address associated with a high-privilege user on a high-trust IDP (e.g., an administrator's Google account). The application, often configured to trust any valid token from any registered IDP based solely on issuer and subject claims, fails to verify the trust level of the issuing IDP. This allows the attacker to obtain a valid token from the low-trust IDP and gain administrative access to the application, effectively bypassing the robust security controls of the high-trust IDP.

These findings collectively underscore a fundamental shift required in security thinking: moving beyond mere token validation to a more comprehensive approach that considers token scope, binding, and the explicit trust levels of identity providers in a distributed environment.

Technical Deep Dive

▶ Watch: Scenario 1: Breaking microservices with token replay (4:40)

The talk provides a detailed technical examination of three distinct attack scenarios, each exploiting specific vulnerabilities in how OAuth, OIDC, and JWTs are implemented and validated in modern microservice architectures.

Scenario 1: Breaking Microservices with Token Replay (Scope Confusion)

This attack targets applications where an API gateway performs initial token validation, then routes requests to various backend microservices. The vulnerability arises when the token's scope is too broad, or when downstream microservices don't re-validate the token's intended scope for their specific function.

Architecture:

• Client: Makes requests.
• Reverse Proxy/Gateway: Validates the incoming token (e.g., checks signature, expiration). Once validated, it routes the request to the appropriate microservice.
• Microservices: Account Service, Transaction Service, Internal Services, Configuration Service. These services are behind the gateway, some potentially not publicly exposed or documented.

Attack Flow:

1. An attacker, as a legitimate user, logs into the application and obtains a valid token, typically scoped for public-facing services (e.g., user profile, basic transactions).
2. Using a proxy tool like Burp Suite's Repeater, the attacker observes the legitimate requests and their associated tokens.
3. The attacker then attempts directory traversal or endpoint enumeration by modifying the request path to probe for internal services. For example, if the initial request was /api/userprofile, the attacker might try /api/internal/config, /api/admin, or /../internal/service. Burp Intruder can automate this enumeration with common wordlists.
4. A key indicator of success is a change in the Server header in the response. Shah demonstrates this by showing a transition from an express js server header to a Django 4.2.17 header, indicating that the request successfully reached a different, internal service. This service, likely not intended for direct public access, is now reachable.
5. Once an internal service is identified (e.g., an API/o/users endpoint common in Django admin interfaces), the attacker replays the same token obtained earlier. Because the token's original scope was not granularly enforced by the gateway for specific downstream services, and the internal service itself might not perform deep scope validation, the attacker gains access to privileged functions (e.g., listing super admin users in the Django admin).

Root Cause: The gateway validates the token's existence and signature but not its specific authorization for the requested backend service. The token's broad scope, coupled with a lack of granular authorization checks at the microservice level, allows for privilege escalation.

Scenario 2: Bearer Token Replay (MFA Bypass Post-Authentication)

This attack leverages the "token as currency" principle, where a stolen bearer token grants full access without requiring re-authentication, even if the initial login involved MFA.

Concept:

• Bearer Token: A token that grants access to the bearer. Anyone in possession of the token can use it. It's not cryptographically bound to the client's identity or device.
• MFA Bypass: MFA secures the authentication phase (logging in). Once a valid token is issued, subsequent access requests using that token do not typically re-invoke MFA. If the token is stolen, the attacker bypasses MFA entirely.
• Increased Blast Radius: Unlike traditional session hijacking, where a session cookie is tied to a specific application, an SSO token can grant access to multiple integrated services and internal systems, depending on its scope.

Attack Flow (Microsoft Storm-2372 example):

1. Attackers create a sophisticated phishing scenario, sending a malicious link to a user.
2. The user, believing they are on a legitimate Microsoft login page, enters their credentials and completes the MFA challenge.
3. A malicious server (controlled by the attacker) intercepts the issued token. This can happen through various means, such as a compromised client-side script exploiting a local storage vulnerability or a malicious proxy.
4. Once the attacker possesses the token, they can use it from any device or location to access the user's Microsoft account and associated services, entirely bypassing the initial MFA. The token is not tied to a specific session, device, or geolocation.

Mitigation: Demonstration Proof of Possession (DPoP) Tokens

Shah introduces DPoP tokens as a robust mitigation. DPoP tokens bind the token to a cryptographic key pair, where:

• A private key resides securely on the client's device (e.g., laptop, mobile app, browser local storage).
• A public key is embedded or fingerprinted into the token itself.
• When the client sends a request to the API server, it includes the token and a cryptographic proof generated using its private key.
• The API server validates that the proof corresponds to the public key in the token, ensuring that the legitimate client (who holds the private key) is indeed making the request. This prevents replay attacks, as a stolen token cannot be used without the corresponding private key.
• Additionally, reducing the expiration time of bearer tokens (e.g., from 6-20 hours to much shorter durations) can limit the window of opportunity for attackers to exploit stolen tokens.

Scenario 3: Federated Identity Confusion (Issuer Trust Level Bypass)

This sophisticated attack exploits applications that rely on multiple IDPs (federated identity) but fail to properly differentiate their trust levels or perform adequate claim validation.

Architecture:

• Enterprise Application: Allows login via multiple IDPs (e.g., Google OIDC, Azure, Internal IDP).
• High-Trust IDPs: Google OIDC, Azure (enforce MFA, domain verification, strong identity assurance).
• Low-Trust Internal IDP: Often used for contractors or specific internal systems; may lack MFA, allow self-registration, and not enforce domain/email verification.

Attack Flow:

1. A legitimate admin user, "Sara" ([email protected]), logs in via a high-trust IDP (e.g., Google OIDC), completes MFA, and receives a high-assurance token, granting admin access to the application. This is the intended secure flow.
2. An attacker (e.g., a malicious contractor) discovers the existence of the low-trust Internal IDP.
3. The attacker attempts to create an account on the Internal IDP using the same email address as the admin: [email protected].
4. Crucially, the Internal IDP allows this self-registration without enforcing MFA, domain verification, or email ownership verification. A malicious account for [email protected] is now provisioned on the low-trust IDP.
5. The attacker then signs in to the Internal IDP using their newly created [email protected] account and their chosen password. Since no MFA or email verification is enforced, the login is successful.
6. The Internal IDP issues a valid token for [email protected].
7. The enterprise application, when presented with this token, performs its default validation: it checks if the token is valid, if it was issued by one of its trusted IDPs (the Internal IDP is on the list), and if the subject (email [email protected]) is recognized.
8. The application fails to check the trust level of the issuing IDP or to distinguish between [email protected] from Google OIDC and [email protected] from the Internal IDP. It blindly grants admin access based on the [email protected] identity claim.

Vulnerable vs. Secure Code (Conceptual):

• Vulnerable Code: trustIssuance allows all three IDPs. Validation logic only checks issuer and subject (email) without considering the IDP's trust level or composite identity.
• Secure Code:
• Explicitly limits admin access to high-trust IDPs only (e.g., if user.role == 'admin': enforce_high_trust_idp()).
• Enforces MFA for privileged roles regardless of the IDP.
• Uses composite identity (issuer + subject) instead of just the email, treating [email protected] from Google and [email protected] from the Internal IDP as distinct identities.
• Performs robust claim validation including account type, MFA status, and email/domain verification.

This attack highlights the critical need for context-aware authorization and explicit trust management in federated identity systems.

Demo / Proof of Concept

▶ Watch: Demo introduction: Token replay using OAuth Lab (6:30)

Bhaumik Shah effectively demonstrated each of the three attack scenarios using practical setups, highlighting the ease with which these vulnerabilities can be exploited in misconfigured systems.

Demo 1: Breaking Microservices with Token Replay

This demonstration showcased how a seemingly innocuous token could be leveraged to access internal services.

1. The speaker began by logging into a simulated banking application, obtaining a standard user token.
2. Using Burp Suite, the primary tool for this demo, the legitimate request was sent to the Repeater.
3. Shah then manually manipulated the URL path, attempting to discover hidden endpoints. He explained that Burp Intruder could automate this enumeration process.
4. The critical moment occurred when a modified request, probing for an internal path, returned a Server header indicating Django 4.2.17, a clear change from the previous express js server. This signified that the request had successfully bypassed the gateway's routing logic and reached an internal Django-based service not intended for public access.
5. Finally, the speaker showed how the original, broadly scoped token could be replayed against this newly discovered internal endpoint, specifically targeting API/o/users (a common Django admin endpoint for user listings). This successfully granted access to internal user data, demonstrating privilege escalation through token replay and scope confusion. The demo environment was hosted on oathlab.sec.securify.co, allowing attendees to try it themselves.

Demo 2: Bearer Token Replay

This demonstration illustrated the stark reality of MFA bypass once a bearer token is compromised.

1. The demo started with a standard user login, including successful MFA completion, into a single sign-on (SSO) enabled application.
2. Shah then simulated an attacker's setup: a malicious server designed to capture tokens. He explained that a client-side vulnerability (e.g., an XSS flaw allowing a payload to extract tokens from local storage) could be used to send the token to this server.
3. A payload was conceptually sent to the user, and upon interaction (e.g., clicking a link), the token was "grabbed" from the user's browser storage.
4. The Burp Suite poll server, set up by the attacker, received the stolen token.
5. With the token in hand, the attacker (Shah, in this case) simply replaced the authorization header in his own browser or a new request. Crucially, he emphasized that no further login, password, or MFA was required.
6. The attacker immediately gained full access to the user's profile and application functionalities, demonstrating that MFA protects the authentication step, but a stolen bearer token bypasses all subsequent authorization checks.

Demo 3: Federated Identity Confusion

This complex demonstration highlighted the dangers of trusting multiple identity providers without adequate trust differentiation.

1. The scenario setup involved an enterprise application offering three IDP options: Google OIDC, Azure, and an "Internal IDP" (typically for contractors).
2. A legitimate admin user, "Sara" ([email protected]), logged in via Google OIDC, completing MFA and receiving a high-assurance token, granting her admin access. This represented the secure, intended flow.
3. The speaker then switched to the attacker's perspective. The attacker, knowing about the Internal IDP, attempted to self-register an account using Sara's admin email: [email protected].
4. The Internal IDP, configured with lax security, allowed this self-registration without requiring MFA, domain verification, or email ownership confirmation. A malicious [email protected] account was successfully created on the low-trust IDP.
5. The attacker then logged into the Internal IDP using this newly created account. Since no MFA or email verification was enforced, a token was issued by the Internal IDP for [email protected].
6. The crucial part of the demo showed that when this token from the low-trust Internal IDP was presented to the enterprise application, the application, configured to trust any of its registered IDPs based on issuer and subject (email), granted admin access to the attacker.
7. Shah visually compared the legitimate token (from Google) with the malicious token (from the Internal IDP), pointing out that while minor claims differed, the core issuer and subject (email) were sufficient for the vulnerable application to grant access. This vividly demonstrated how a lack of IDP trust differentiation and composite identity checks leads to privilege escalation.

These demonstrations provided compelling evidence for the vulnerabilities discussed, making the technical explanations tangible and underscoring the urgency of implementing the proposed mitigations.

Defensive Implications

▶ Watch: Leveraging Burp Suite repeater for token attacks (7:50)

The detailed analysis of modern token-based attacks provides a clear roadmap for defenders to strengthen their application security postures. The mitigations proposed by Bhaumik Shah address the core weaknesses exposed in each attack scenario:

1. Granular Token Scoping and Segregation for Microservices:

• Enforce Least Privilege: Tokens should be issued with the absolute minimum scope required for a specific task or service. Do not issue broadly scoped tokens that can access multiple, unrelated services.
• Microservice-Level Validation: While an API gateway can perform initial token validation, individual microservices should also validate the token's scope to ensure it's authorized for the specific resource or action being requested. A token for a "transaction service" should not be usable by an "internal configuration service," even if the gateway initially deemed it valid.
• Separate OAuth Configurations: For internal services that should never be publicly accessible, consider using entirely separate OAuth configurations, including distinct client IDs and client ID registrations. This creates a clear segregation, akin to separating test and production environments, making it harder for tokens from one domain to be used in another.

1. Mitigating Bearer Token Replay with DPoP and Reduced Expiration:

• Implement Demonstration Proof of Possession (DPoP) Tokens: This is the most robust defense against token replay. DPoP tokens cryptographically bind the token to the client's device using a public/private key pair. The private key remains on the client, and the public key is embedded in the token. Each request includes a cryptographic proof generated by the client's private key, which the server verifies against the public key in the token. This ensures that only the legitimate client (possessing the private key) can use the token, rendering stolen tokens useless for replay.
• Reduce Token Expiration Times: Shorten the lifespan of access tokens. While this might slightly increase the frequency of token refreshes, it significantly reduces the window of opportunity for attackers to exploit a stolen token. Instead of 6-20 hours, consider minutes or a few hours, balanced against user experience.
• Consider Session Binding: While DPoP is superior, other forms of session binding (e.g., binding tokens to specific IP addresses or user-agent strings) can add layers of defense, though these can be more prone to false positives or difficult to manage in dynamic environments.

1. Securing Federated Identity with Trust Differentiation and Robust Claim Validation:

• Differentiate IDP Trust Levels: Not all identity providers are created equal in terms of security controls. Applications must explicitly recognize and enforce different trust levels for various IDPs. For instance, an internal IDP allowing self-registration without MFA should be designated as low-trust.
• IDP-Bound Privileges: Critical roles, especially administrative access, should only be grantable through high-trust IDPs (e.g., Google, Azure) that enforce strong authentication, domain verification, and robust identity assurance. Low-trust IDPs should be restricted to non-admin or limited-privilege user roles.
• Composite Identity: When validating user identity, combine the issuer and the subject (e.g., email) to form a unique composite identity. This prevents an [email protected] from a low-trust IDP from being treated identically to [email protected] from a high-trust IDP. They are, in fact, two distinct identities from a security perspective.
• Comprehensive Claim Validation: Go beyond basic issuer and subject checks. Validate all relevant claims in the token, including:
• Account Type: Does the token claim a specific account type (e.g., "contractor," "employee") that aligns with the IDP's trust level?
• MFA Status: Verify if MFA was enforced by the IDP during authentication, especially for privileged roles.
• Email/Domain Verification: If self-registration is allowed, ensure robust email ownership and domain verification processes are in place for the IDP, and that the application validates these claims.
• Trust Tier: Explicitly check for claims indicating the trust tier of the IDP or the authentication event.

By implementing these defensive strategies, organizations can significantly reduce their exposure to modern token-based attacks, ensuring that their distributed authentication and authorization systems remain secure against sophisticated adversaries.

Key Takeaways

• Tokens are currency: Treat OAuth/OIDC tokens as highly valuable assets. Their compromise can lead to widespread unauthorized access, bypassing even strong authentication like MFA.
• Granular Scoping is Crucial: Broadly scoped tokens are a major vulnerability. Implement granular token scopes and ensure all microservices re-validate the token's specific authorization for their requested actions, not just its general validity.
• DPoP Tokens are the Future: To prevent bearer token replay attacks, adopt Demonstration Proof of Possession (DPoP) tokens. These bind the token to the client's cryptographic key, making stolen tokens useless without the corresponding private key.
• Differentiate Identity Provider Trust: Applications integrating with multiple IDPs must explicitly differentiate their trust levels. High-privilege access should only be granted through high-trust IDPs that enforce robust security controls.
• Beyond Basic Validation: Token validation must go beyond merely checking issuer and subject. Implement composite identity and comprehensive claim validation (MFA status, account type, email/domain verification) to prevent federated identity confusion.
• Reduce Token Lifespan: Shorter token expiration times limit the window of opportunity for attackers to exploit stolen tokens, reducing the blast radius of a compromise.

About the Speaker(s)

Bhaumik Shah is the founder of Security AI, a company focused on security solutions. With over 17 years of experience, he has a deep background in identity systems, cloud security, and infrastructure. Prior to founding Security AI, Bhaumik held security guardian roles at prominent organizations such as AWS, Fire, and the World Bank, where he tackled challenging security problems. He occasionally shares his security insights and expertise on his YouTube channel, Cybersec TV.