OAuth misconfigurations widen identity risk across connected applications

At a glance

What this is: Descope examines how OAuth misconfigurations in redirect handling, token scopes, storage, and identity mapping create account takeover and token theft risk across connected applications.

Why it matters: IAM, PAM, and NHI teams need to treat OAuth as a governance problem, because small validation and lifecycle gaps in connected apps can widen blast radius across both human and machine access paths.

Context

OAuth is an authorization framework, but the security outcome depends on how each integration validates redirects, stores tokens, and maps identity claims. When those controls are loose, the problem is no longer OAuth design, but governance over the credentials and claims that flow through it.

For identity programmes, the relevant boundary is not just user login. OAuth touches non-human credentials, third-party trust, and account linking, so misconfiguration in one connected app can expose access across many others. That makes lifecycle control, scope discipline, and immutable identity handling central to the topic.

Key questions

Q: What breaks when redirect URI validation is too permissive in OAuth?

A: Permissive redirect URI handling can misroute authorization codes or tokens to unintended endpoints, which expands the attack surface for open redirect abuse and token interception. Exact string matching closes that loophole and makes the callback path auditable rather than approximate.

Q: Why do broad OAuth scopes increase breach impact?

A: Broad scopes turn one consent decision into multiple reachable resources, which gives an attacker a much larger blast radius if the app is compromised. Mail, drive, calendar, and directory access can expose credentials, internal documents, and organisational structure. The wider the bundle, the more likely the compromise becomes a workspace-level incident rather than a single-app event.

Q: What do security teams get wrong about OAuth and connected apps?

A: Teams often assume a delegated app is safe because it was approved once, but approval is not the same as ongoing trust. OAuth grants can outlive the original need, inherit too much scope, or become a bridge into multiple SaaS tenants. Security teams should treat each grant as a revocable access path, not a permanent integration.

Q: When should organisations re-evaluate their OAuth controls?

A: Organisations should re-evaluate OAuth controls whenever they add a provider, change a redirect flow, onboard a third-party integration, or allow identity linking across domains. Those moments change the trust boundary and are where hidden assumptions most often surface.

Technical breakdown

Redirect URI validation failures open token interception paths

OAuth redirect handling depends on exact matching between the provider’s expected callback and the application’s approved return location. If partial matches, wildcard paths, or open redirects are allowed, an attacker can route an authorization code or token through an attacker-controlled endpoint and then replay it. This is an implementation failure, not a flaw in OAuth itself. The risk expands when multiple providers are accepted, because each integration adds a separate validation surface. In practice, redirect logic becomes a trust boundary: if that boundary is loose, the token is no longer bound to the intended application context.

Practical implication: enforce strict, path-specific redirect validation across every OAuth provider and callback path.

Token scope and storage determine blast radius after compromise

OAuth tokens are temporary credentials, but temporary does not mean low-risk. If scopes are broader than the task requires, one stolen token can expose repositories, APIs, or multiple services rather than a single function. If tokens are stored in localStorage, logs, browser tooling, or unencrypted files, a compromise of the host or tooling immediately becomes a credential replay issue. JWTs add another wrinkle: they are integrity-protected by signature, not confidential by default, so claims must never carry sensitive data. Scope and storage design together decide how far an intrusion can spread.

Practical implication: minimise token scope, store tokens in hardened locations, and revoke anything exposed in logs, files, or developer tooling.

Mutable identity claims create account-linking and takeover risk

OAuth identity handling fails when applications treat changing attributes such as email address or domain as proof of identity. Those fields can be recycled, reassigned, or spoofed, which means an account-linking decision based on them can outlive the original owner’s control. The article’s examples show that this is especially dangerous in social login and provider-bridging flows, where a service assumes the claim remains stable across time. Reliable authorisation depends on immutable identifiers and verified ownership, not on convenient but mutable attributes.

Practical implication: base authorisation and account linking on immutable claims, and separate identity proofing from mutable email or domain values.

Threat narrative

Attacker objective: The attacker aims to steal reusable OAuth credentials or exploit identity-linking flaws to gain unauthorized access across connected applications.

1. Entry occurs through a weak OAuth integration, most often by exploiting redirect manipulation, overbroad scopes, or insecure token handling in a connected application.
2. Credential access follows when the attacker captures an authorization code, access token, or reused integration token from the flawed flow.
3. Escalation happens when the token grants broader permissions than the initial task required, allowing access to additional repositories, services, or user accounts.
4. Impact is achieved through account takeover, unauthorized data access, or reuse of stolen tokens across multiple connected systems.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth failure is usually governance failure, not protocol failure: The article’s core pattern is that implementation decisions, not OAuth itself, create the exploit surface. Redirect checks, token storage, and claim validation are governance controls over trust boundaries, not developer convenience details. When those controls are inconsistent across connected apps, the identity plane fragments and the organisation inherits a larger attack surface than any one application team can see. Practitioners should treat OAuth as a distributed trust problem, not a login feature.

Mutable identity claims are a broken assumption in federated access: Email address and domain were designed for communication, not durable authorisation. That assumption fails when those attributes are used to bind accounts over time, because ownership can change while access remains active. The implication is that identity governance cannot rely on attributes that may be reassigned or recycled after onboarding, especially in external federation and social login.

Token scope is the real blast-radius control for connected applications: OAuth tokens are often operationally treated as narrow session artefacts, but the article shows that scope decisions define how far a compromise can travel. A token with excessive permissions turns a single leak into a multi-system event, and reuse across integrations compounds that effect. The practitioner conclusion is simple: blast radius is set at issuance time, not after compromise detection.

Connected app ecosystems need lifecycle governance, not just authentication hardening: The Booking.com, Expo, and GitHub examples all show that one weak integration can affect many downstream services. That creates a lifecycle problem across third-party access, token revocation, and provider changes, not just a point-in-time configuration issue. Identity programmes should govern OAuth connections as living dependencies with onboarding, review, and offboarding states.

Redirect trust is a named control gap, not a minor coding detail: Path-specific callback validation is the difference between a bounded authorization flow and a token interception path. The exploit pattern persists because teams assume provider-level domain checks are enough, when the application’s path and return handling still decide where secrets land. The practitioner takeaway is to audit redirect trust as its own control domain.

From our research library:

• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

OAuth governance is becoming a lifecycle discipline: Teams can no longer treat federated login as a one-time integration task. Every provider, proxy, and callback path adds a trust boundary that has to be reviewed, revocated, and retired with the same discipline used for other non-human credentials.

Mutable identity creates latent access debt: When authorisation depends on email addresses or domain ownership, access can survive long after the original entity has changed. That is a governance debt problem, not a protocol problem, and it becomes more visible as organisations increase reliance on social login and external federation.

For practitioners

• Enforce strict redirect matching Require exact, path-specific validation for every redirect_uri and return URL, including callback endpoints used by third-party providers.
• Minimise token scope by design Grant only the permissions required for the immediate workflow, especially for integrations that can reach repositories, deployment systems, or shared APIs.
• Harden token storage and revocation Keep OAuth tokens out of localStorage, logs, debug output, and unencrypted server files, and revoke any token exposed through those paths.
• Replace mutable claims in account linking Use immutable identifiers for federation and account merging, and do not authorise users solely on email address or domain ownership.
• Review third-party OAuth dependencies Inventory every external OAuth provider, proxy, and intermediary, then verify how each one validates callbacks, handles claims, and supports deprecation.

Key takeaways

• OAuth misconfigurations create risk because validation, storage, and identity mapping controls are often weaker than the protocol itself.
• The article’s examples show how redirect flaws, excessive scopes, and mutable claims can widen the blast radius across connected applications.
• Identity teams should govern OAuth as a lifecycle problem, with strict callback validation, immutable identifiers, and fast token revocation.

Key terms

• Redirect URI: A redirect URI is the endpoint where an authorization server sends the user back after a login or consent step. In secure OAuth implementations, it must be pre-registered and matched exactly so an attacker cannot divert the response to a malicious destination.
• Token scope: Token scope is the set of actions and systems a credential can reach. In non-human identity governance, narrow scope limits blast radius, while broad scope lets a stolen token publish packages, access cloud services, or mutate repositories far beyond its intended purpose.
• Mutable Identity Claim: An identity attribute such as email address or domain name that can change over time or be reassigned to another party. If used for authorisation or account linking, it can create takeover risk because the claim does not reliably prove continuing ownership.
• OAuth Intermediary: A third-party service that handles or forwards OAuth traffic between an application and the identity provider. Intermediaries expand the trust boundary, so their callback handling, token treatment, and deprecation process must be governed as part of the integration.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.