Localhost Redirect URI Impersonation is an attack against apps that use localhost as an OAuth or OpenID Connect redirect URI. An attacker persuades the authorisation server to send the callback to a local listener they control, then captures the code or token and completes sign-in or account linkage as the victim.
How localhost redirect URI impersonation works
This attack abuses the trust OAuth and OpenID Connect place in a localhost callback. Instead of the intended app receiving the authorization response, a local listener controlled by the attacker captures the code or token and can finish the victim’s sign-in or account-linking flow.
The key failure is not “localhost” by itself, but the assumption that anything listening on a loopback redirect is the legitimate client. That assumption is fragile when the platform, browser, malware, or another local process can bind the same callback path first, intercept the response, or influence where the authorization server sends it.
For a deeper explanation of the underlying flow, see OAuth 2.0 and OpenID Connect Guide for Identity Teams, which covers redirect uri, client types, tokens, and the mistakes that make these flows unsafe.
Why this attack is dangerous
When the callback is captured, the attacker can steal an authorization code, access token, or related session material and turn a legitimate login into account takeover, unwanted account linking, or unauthorized access. The impact is strongest where the flow is used for initial sign-in, token exchange, or delegated access into other services.
It is especially dangerous because the victim may complete the login normally while the attacker quietly receives the useful artifact. That makes the attack look like an ordinary browser redirect unless the application, browser, or authorization server validates redirect behavior very precisely.
Readers who want the adjacent redirect and callback abuse patterns should also review Open Redirect Guide, which explains why redirect handling becomes a code and token theft problem when matching is too loose.
Where exposure usually comes from
Exposure tends to show up in native apps, desktop clients, developer tools, and agent or helper workflows that rely on localhost callbacks for OAuth or OIDC. The risk increases when the redirect URI rules are broad, when port or path binding is predictable, or when the app accepts any local listener that looks close enough to the intended callback endpoint.
Organisations should verify which apps use localhost redirect URIs, whether those apps are internet-exposed in practice through browser redirects, and whether vendor guidance or protocol profiles require stricter exact matching, PKCE, or alternative callback patterns. The right source of truth is the app’s OAuth/OIDC design and the authorisation server’s redirect policy, not assumptions about loopback safety.
The broader protocol and client-registration issues that often surround this pattern are covered in OAuth Client ID Metadata Documents Guide, especially where trust policy and localhost impersonation concerns overlap.
How to reduce the attack surface
The strongest defence is to avoid treating localhost as a casual trust boundary. Use exact redirect URI registration, restrict clients to the smallest viable callback set, and prefer flows and client types that reduce the value of a captured response. Where localhost must be used, make the callback handling strict, predictable only to the legitimate app, and resistant to hijack by another local process.
Controls that matter here include redirect URI validation, proof that the response came from the right client, short-lived codes, and sender-constrained or otherwise hardened token handling where available. Teams should also review whether their login UX can be delivered with a less impersonation-prone pattern, particularly for high-value enterprise sign-in and linking flows.
For protocol-level hardening guidance, OAuth 2.0 Security Best Current Practice Guide is the best companion reference, because it ties redirect validation and code injection resistance to the modern OAuth security baseline.
Risk and Threat Considerations
This attack matters because it converts a trusted local callback into a token or code interception point. The threat is not only credential theft, but also delegated access abuse, session capture, and account-linking manipulation when the captured response is still usable after the victim’s browser finishes the flow.
Failure mechanism: The authorization server delivers the response to a localhost endpoint that the attacker can bind, mimic, or influence before the legitimate client processes it.
Impact: The attacker can capture the authorization artifact, complete authentication as the victim, and potentially gain access to the victim’s account or linked services.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | OAuth/OIDC redirect URI handling is central to this callback impersonation attack. |
| Recommendation — Enforce exact redirect URI validation and hardened OAuth/OIDC flow requirements. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The attack targets authentication and redirect handling in digital identity flows. |
| Recommendation — Use phishing-resistant and tightly bound authentication flows for high-value sign-ins. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Captured codes or tokens let an attacker complete sign-in through a broken authentication path. |
| Recommendation — Treat intercepted authorization artifacts as authentication failures and block replayable flows. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The attack steals or reuses authenticating material that must be protected across its lifecycle. |
| Recommendation — Protect short-lived authorization artifacts and revoke or rotate compromised credentials promptly. | ||
Practitioner Guidance
Why practitioners should care: This is a client and redirect design problem, not just a browser quirk. Security teams should treat localhost callbacks as part of the authentication attack surface and review them wherever OAuth or OIDC is used for desktop, native, or helper-app sign-in.
What to watch for: Reused callback patterns, broad redirect registration, weak local port assumptions, and login flows that still succeed even when the callback target changes are all signs that the flow deserves closer review.
Practitioner takeaway: If a local callback can be impersonated without breaking the login, the redirect design is too forgiving for a high-trust authentication flow.