TL;DR: Unosecur says weak redirect URI validation in OAuth flows can let attackers intercept authorization codes or access tokens, then reuse them for account takeover and session hijacking while bypassing passwords and MFA. The real control gap is application-layer trust validation, not the identity provider itself.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “OAuth Token Theft via Redirect Manipulation”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Weak redirect URI validation can turn a normal OAuth login into token theft and session hijacking without defeating passwords or MFA.
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
👉 Read Unosecur's analysis of OAuth token theft via redirect manipulation →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full 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.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: OAuth token theft via redirect manipulation and session hijacking