OAuth token theft via redirect manipulation and session hijacking

At a glance

What this is: This analysis explains how OAuth token theft can occur through redirect manipulation, turning a normal login into token interception and session hijacking.

Why it matters: It matters because IAM teams often harden authentication while leaving redirect validation, token handling, and post-login monitoring weak enough for account takeover.

👉 Read Unosecur's analysis of OAuth token theft via redirect manipulation

Context

OAuth token theft via redirect manipulation is an application-layer trust failure, not a password-cracking problem. The attack succeeds when a relying application accepts an unsafe redirect URI during an otherwise legitimate OAuth flow, allowing the attacker to intercept the resulting code or token.

That distinction matters for IAM and SaaS governance because the identity provider may authenticate correctly while the application silently misroutes the token. The control boundary therefore extends beyond login success to redirect validation, PKCE enforcement, and token monitoring across the full OAuth session lifecycle.

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 OAuth tokens bypass MFA in real attacks?

A: OAuth tokens bypass MFA because the attacker reuses a valid authorization artifact after it has already been issued. Once the token exists, the identity provider may see the request as legitimate, so MFA is no longer part of the transaction.

Q: How do security teams know if OAuth sessions are being abused?

A: Look for repeated token redemptions, unfamiliar geolocation, device changes, and abnormal application access immediately after a successful login. Those signals often reveal misuse that conventional sign-in alerts will miss. Correlating identity provider, application, and proxy logs gives the clearest view of session abuse.

Q: What should IAM teams do when a token interception risk is found in an application?

A: Revoke the suspect access and refresh tokens, remove unsafe redirect URIs, and verify that PKCE is enforced on every flow that can be intercepted. Then review connected OAuth clients and SaaS integrations for similar misconfigurations. The goal is to eliminate the specific trust path that allowed the token to leave the intended application boundary.

Technical breakdown

How weak redirect URI validation enables token interception

OAuth redirect URIs tell the authorisation server where to send the response after login. If an application allows wildcards, loose matching, or unreviewed redirect values, an attacker can register or exploit an attacker-controlled endpoint and receive the code or token instead of the intended app. The identity provider still issues a valid response, which makes the failure hard to spot because the compromise occurs after authentication. The key issue is that the application has failed to bind the response to a precise destination.

Practical implication: enforce exact-match redirect URI allowlists and remove wildcard or loosely validated redirects.

Why PKCE matters in code interception attacks

Proof Key for Code Exchange, or PKCE, adds a verifier that links the authorisation request to the token exchange. That matters because even if an attacker captures an authorisation code, the code alone is not enough to redeem the token without the original verifier. PKCE does not fix broken redirect validation, but it reduces the value of intercepted authorisation codes and closes a common interception path in public clients and mobile or browser-based flows.

Practical implication: require PKCE across every OAuth flow where code interception would otherwise be useful to an attacker.

Why token monitoring must follow successful login

OAuth abuse often looks legitimate in authentication logs because the victim really did sign in. The abnormality appears after the session begins, when the token is redeemed from an unexpected IP, device, or geography, or when a token is used more than once from different places. That means detection has to watch post-authentication behaviour, not only login success. Without token binding, anomaly detection, and application log correlation, teams may not see the abuse until data access or lateral movement has already happened.

Practical implication: correlate identity provider logs, application logs, and proxy telemetry to detect token misuse after authentication.

Threat narrative

Attacker objective: The attacker wants to hijack a valid OAuth session and use it to access the victim's application data without needing the password or MFA challenge.

1. Entry occurs when the victim follows a crafted OAuth login link delivered through phishing, chat, or embedded content.
2. Credential access happens when weak redirect URI validation sends the authorisation code or access token to an attacker-controlled destination.
3. Escalation follows when the attacker redeems the valid token and assumes the victim's authenticated session inside the target application.
4. Impact is account takeover, data exposure, and prolonged misuse of legitimate SaaS access that is difficult to distinguish from normal login activity.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth redirect trust is a control plane, not a login detail. This attack works because applications often treat redirect handling as a routing concern rather than an identity control. Once the redirect destination is too permissive, the application itself becomes the trust failure point even when the identity provider performs correctly. Practitioners should treat redirect validation as part of authentication governance, not as an implementation footnote.

Exact-match redirect enforcement is the real boundary that determines whether OAuth remains safe. Wildcards, broad allowlists, and unreviewed client registrations expand the attack surface in ways many teams still underestimate. The practical consequence is that a legitimate login can be converted into token theft without defeating the authentication factors themselves. That makes application registration governance a core identity security control, not a developer convenience.

Token lifecycle visibility matters more than login success alone. If organisations only measure successful sign-in events, they miss the point at which the stolen token is actually abused. The trust decision now extends into token redemption, reuse, and abnormal session behaviour across SaaS environments. The implication is that IAM programmes need post-authentication telemetry, not just stronger front-door controls.

Ephemeral token misuse is the identity blast radius for OAuth-based SaaS access. A single intercepted token can give an attacker the same access path the user already had, including access to data, APIs, and connected services. That collapses the assumption that a trusted login equals a trusted session. Practitioners should rethink how much authority a bearer token carries once it leaves the intended redirect path.

OAuth governance now overlaps with third-party and SaaS access governance. The article's own risk statement shows that third-party authentication is no longer isolated from application registration, session monitoring, and integration hygiene. This is where identity governance, API access, and SaaS oversight meet. Teams should evaluate OAuth clients, redirect rules, and token handling as one control surface rather than separate tasks.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

OAuth redirect governance is now part of identity governance. Teams that only manage usernames, passwords, and MFA will miss the control point that actually decides whether a token lands in the right application. Redirect validation, client registration review, and token monitoring need to be governed together because the compromise occurs after successful authentication, not before.

Post-authentication telemetry is the deciding control for hijacked sessions. The practical question is no longer whether a user logged in, but whether the token was redeemed in the place and manner the application expected. That shifts programme design toward correlated identity, proxy, and application logs rather than relying on authentication events alone.

Third-party and SaaS access paths need tighter OAuth governance. The article's threat model shows that externally connected applications can become the weakest part of a trusted login chain. According to the Ultimate Guide to NHIs, 92% of organisations expose NHIs to third parties, which reinforces how often delegated trust becomes the attack surface.

For practitioners

• Enforce exact-match redirect allowlists Review every OAuth client registration and remove wildcard, prefix, or loosely validated redirect URIs that can be abused for token interception.
• Require PKCE on all applicable flows Make Proof Key for Code Exchange mandatory wherever code interception would let an attacker redeem a captured authorisation code.
• Monitor post-login token abuse Correlate identity provider logs, application logs, and reverse proxy telemetry to flag token redemption from new geographies, devices, or IP ranges.
• Rotate and revoke suspicious OAuth credentials Treat suspected token theft as an account-level incident and revoke both access and refresh tokens before the session can be reused.
• Audit OAuth client governance regularly Review connected apps, redirect destinations, and over-permissive OAuth scopes on a fixed cadence so unsafe client registrations do not persist unnoticed.

Key takeaways

• Weak redirect URI validation can turn a normal OAuth login into token theft and session hijacking without defeating passwords or MFA.
• The attack is hard to spot because authentication logs may show a successful login even when the token is delivered to an attacker-controlled domain.
• Exact-match redirect controls, PKCE enforcement, and post-login token monitoring are the controls that reduce the blast radius.

Key terms

• OAuth Redirect Handling: OAuth redirect handling is the process a client uses to send a user to an authorization endpoint and receive the result back safely. In MCP implementations, weak redirect validation can let a malicious server supply dangerous destinations. Strong handling requires scheme checks, origin control, and safe browser or process invocation.
• Authorization Code Interception: An attack where a malicious process steals the authorization code before the intended client can redeem it. The threat is strongest in public clients and redirect environments that can be observed or hijacked. PKCE is the control designed to prevent the stolen code from being useful.
• PKCE: Proof Key for Code Exchange is a binding mechanism that links the authorization request to the later token exchange. It helps stop authorization code interception and injection by requiring proof that the same client that started the flow is the one completing it.
• Token Replay: Token replay is the reuse of a valid access or refresh token by someone other than the intended client. The token may still be unexpired and cryptographically correct, so the compromise often shows up only through context anomalies such as location, device, or session overlap.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• Exact redirect validation patterns for OAuth client registrations and application allowlists
• Token monitoring examples that flag abnormal redemption, geolocation changes, and replay behaviour
• Mitigation guidance for PKCE, short-lived tokens, and client or device binding
• Logging sources and alert conditions for OAuth abuse across SaaS environments

👉 The full Unosecur post covers the attack flow, detection signals, and mitigation steps in more detail.

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.