Shadow OAuth: Escalating Privileges and Finding Persistence via Over-Permissioned Corporate Integrations

• February 3, 2026
• By Secnora

OAuth is often called the universal key of the modern web. From “Sign in with Google” to connecting a Slack bot to an internal workspace, OAuth controls how users authenticate and how applications request access to data on their behalf. It has become the default standard for identity and authorization across web, mobile and cloud platforms. Because it works quietly in the background, it is trusted by millions of users and deeply embedded into everyday products that people rely on without giving it much thought.

For pentesters and bug hunters, OAuth security tells a very different story. It represents a broad and often misunderstood attack surface where small implementation mistakes can lead to serious impact. Weaknesses in scopes, redirect URIs, token storage, refresh logic or consent handling can expose user accounts, leak sensitive data or enable privilege escalation. Understanding OAuth flows in detail along with common misconfigurations seen in real-world applications is now essential for finding meaningful, high-impact vulnerabilities.

What is OAuth?
OAuth 2.0 is an authorization framework, not an authentication protocol. Its purpose is to let one application securely access specific data or services from another system on your behalf, without ever asking for or handling your password. Instead of sharing credentials, OAuth creates a controlled permission flow that limits what the application can do and for how long, reducing risk if something goes wrong.

The Key Players:

• Resource Owner: The individual or entity that owns the data and has the authority to grant limited access to it.
• Client: The application that is requesting permission to access specific data or perform actions on the resource owner’s behalf.
• Authorization Server: The trusted service responsible for verifying permissions and issuing access tokens, typically operated by an identity or platform provider such as Google, Microsoft or Okta.
• Resource Server: The API or service that actually stores the protected data and enforces access based on the tokens it receives.

7 Common OAuth Misconfigurations Abused in the Wild
In security assessments, the focus is on identifying areas where the actual implementation  deviates from established security standards and best practices. Today, a detailed assessment uncovered seven critical vulnerabilities that pose significant risks. Each of these issues highlights weaknesses that could be exploited by attackers if left unaddressed. The findings emphasize the importance of rigorous security reviews and adherence to secure coding guidelines. Prompt mitigation and continuous monitoring are essential to reduce exposure and maintain system integrity.

Improper redirect_uri Validation
An authorization server must issue the authorization code only to an exact, pre-registered redirect URI. When validation relies on regex patterns or broad wildcards such as https[:]//*[.]example[.]com, the trust boundary breaks. An attacker can register or control a matching subdomain and capture the authorization code. This results in account takeover or token theft without exploiting the user directly. The weakness sits entirely in server-side validation logic.

• POC: https[:]//oauth-provider[.]com/auth?client_id=123&redirect_uri=https[:]//attacker[.]com

Missing or Predictable state Parameter
The state parameter is a core defense against CSRF attacks in OAuth flows. It is generated by the client, stored securely and validated on return to ensure the authorization response matches the original request. When this value is missing, reused or predictable, that binding is lost. The authorization server may still complete the flow assuming the request is legitimate. This creates a gap where external input can influence the login process.

In such cases, an attacker can initiate an OAuth flow using their own account and trick a victim into completing it. The result is OAuth Login CSRF where the victim unknowingly links their session to the attacker’s social identity. This can lead to account confusion, data exposure or full account takeover depending on the application logic. The issue stems from weak session integrity rather than user behavior.

PKCE Downgrade Attacks
Mobile applications and Single Page Apps rely on PKCE (Proof Key for Code Exchange) to protect authorization codes from interception. PKCE binds the authorization request to the token exchange using a one-time secret generated on the client. This mechanism is critical in environments where a client secret cannot be safely stored. Without PKCE, intercepted codes can be reused by an attacker.

• Methodology: Pentesters try to remove the code_challenge from the request. If the server still issues a code, it’s a “Downgrade Attack,” making the code interceptable via local logs or referer headers.

Flawed Token Scoping
Many applications request overly broad permissions by default, even when only limited access is required. Instead of narrowly scoped access, tokens are issued with high-impact privileges such as *.All or Mail.ReadWrite. This violates the principle of least privilege and expands the attack surface unnecessarily. A single access token ends up carrying far more authority than the application’s core functionality demands.

From a security perspective, if the application or token is compromised the attacker gains extensive access to user data and services. What should be a low-impact issue escalates into a full data exposure scenario. The root problem lies in scope design rather than the OAuth protocol itself.

Account Takeover via Mutable Claims
If an application identifies a user by their email claim instead of a unique, immutable sub (subject) ID, an attacker can create an account on a rogue Identity Provider using the victim’s email. Once the account is created, the attacker can authenticate and gain access to the victim’s session or data. This bypasses normal ownership checks and allows unauthorized access without exploiting passwords. The vulnerability arises because email addresses can be changed or duplicated across providers whereas sub values are guaranteed to be unique and permanent. Applications relying on mutable claims risk complete account takeover if proper identifiers are not enforced.

Authorization Code Injection
In this scenario, an attacker intercepts a valid authorization code from their own session and injects it into a victim’s session. If the client fails to verify that the code is bound to the original user session and requests context, the exchange still succeeds. The application then links the victim’s session to the attacker’s identity. This results in silent account takeover without the victim sharing credentials or interacting with a malicious flow.

Implicit Flow Token Leakage
Many legacy applications still rely on response_type=token, which delivers the access token directly in the URL fragment. Although the fragment is not sent to the server, it is easily exposed in real-world usage. Tokens can leak through browser history, shared screenshots, malicious browser extensions, or careless logging. In some cases, referer handling or client-side scripts further amplify the risk. This makes token theft trivial and is why the implicit flow is now strongly discouraged.

Shadow OAuth & Corporate Privilege Escalation

Shadow IT once meant employees buying hardware without IT approval. Today, the risk has shifted to Shadow OAuth where employees authorize third-party tools like AI assistants or email organizers with a single click. These apps quietly gain access to corporate data through OAuth often without any security review. The permissions remain active long after the initial use is forgotten.

The Attack Path: From App to Admin

• Discovery: Attackers enumerate integrated OAuth applications using tools like Grip or PowerShell in Azure environments. This reveals apps that fly under the radar but still hold valid tokens.
• The Scope Trap: A shadow application is identified with excessive permissions that do not match its stated purpose. For example, a simple calendar sync tool requesting ReadWrite.All raises an immediate red flag.
• Exploitation: If the third-party service is breached, its refresh token can be abused to maintain long-term access. This creates a persistent and invisible backdoor into the corporate tenant.
• Escalation: When a high-privilege user such as an IT manager has authorized the app, the attacker effectively inherits those privileges. The OAuth token continues to work even after password resets or MFA enforcement bypassing traditional security controls entirely.

The Security Evolution (2.0 vs. 2.1)
To understand why the industry is moving toward a stricter model, it helps to compare OAuth 2.0 with its successor. OAuth 2.1 is not a new protocol but a consolidation of hard lessons learned from years of real-world attacks. It addresses the inherited weaknesses of OAuth 2.0 by removing flexibility that repeatedly led to insecure implementations.

OAuth 2.0 (The Configurable Framework)

The Logic: “Here are the building blocks; assemble them in whatever way fits your application.” This design prioritized developer freedom and broad adoption over opinionated security choices.

The Result: The flexibility came at a cost. OAuth 2.0 permitted insecure patterns such as the Implicit Flow and treated PKCE as optional. These design choices resulted in widespread token leakage, interception attacks and a long history of preventable compromises.

OAuth 2.1 (The Hardened Standard)

The Logic: “Secure by default, and remove what has proven unsafe.” The goal shifts from configurability to consistency and predictable security outcomes.

The Shift: OAuth 2.1 folds years of best practices into mandatory requirements rather than recommendations.

• No more Implicit Flow: The Authorization Code Flow becomes the only supported approach for all clients.
• Mandatory PKCE: Every client must use a code challenge, eliminating downgrade and interception attacks.
• Strict Redirects: Wildcards are no longer allowed, redirect URIs must match exactly as registered.
• No Cleartext Tokens: Access tokens are explicitly forbidden in URLs and query strings, closing common leakage paths.

Conclusion
OAuth was designed to reduce risk, but often in real environments it is not secured enough. Over-permissioned apps, weak bindings and forgotten integrations turn OAuth into a quiet persistence layer that attackers can abuse long after the initial access. Shadow OAuth shows that the real danger is not 0-day exploits but everyday trust placed in tools that were never reviewed or constrained.

Defending against this means treating OAuth with the same seriousness as credentials and endpoints. Tight scopes, strict redirect handling, immutable identifiers, and continuous review of third‑party integrations are no longer optional. As OAuth 2.1 pushes the ecosystem toward safer defaults, the organizations that adapt early will close off an entire class of attacks that currently operate in plain sight.