Authorization code phishing is an attack that tricks a user into handing over an OAuth or OpenID Connect authorisation code. The attacker then redeems that code at the token endpoint to obtain access and refresh tokens, often by abusing a fake login page or malicious redirect flow.
How Authorization Code Phishing Works
Authorization code phishing targets the handoff between the user’s browser and the OAuth or OpenID Connect flow. The attacker does not need to break the protocol, only to persuade the user to deliver a valid code that can later be redeemed for tokens.
This is dangerous because the authorisation code is a short-lived but highly valuable proof of a completed login or consent step. If an attacker captures it quickly enough, they can turn a single social engineering success into bearer tokens that may outlive the original page session.
The technique often rides on fake login pages, lookalike consent screens, or redirect abuse. It succeeds when users are trained to trust the visual flow more than the actual domain, app origin, or redirect destination.
Why It Is Dangerous in OAuth and OpenID Connect Flows
Authorization code phishing matters because OAuth and OpenID Connect are designed to move trust through redirects. That creates a narrow but critical window where the user, browser, client application, and authorization server must all behave exactly as expected.
If the attacker can intercept the code before it is redeemed, they may obtain access tokens and refresh tokens without ever knowing the victim’s password. That means the compromise can extend beyond the initial sign-in and can persist until the tokens are revoked or expire.
The real failure is not the presence of OAuth itself, but weak binding between the user, client, redirect destination, and token exchange step. The attack exploits confusion at the boundary where the user believes they are completing a legitimate sign-in.
How Organisations Check Exposure
Exposure checks start with mapping every application that uses OAuth or OpenID Connect, including native apps, web apps, internal portals, and third-party integrations. Teams should know which flows are used, which redirect URIs are registered, and which applications receive tokens.
It is also important to review whether users can be lured to untrusted consent pages, fake login portals, or unexpected redirect chains. The Phishing Guide is useful for understanding the broader social-engineering patterns that make this attack effective.
Where OAuth implementations are used by agents, bots, or automation, review whether those workflows rely on user-facing login steps that can be impersonated. AI Agent Authorisation Guide helps readers think about delegated access and approval boundaries that should not be confused with ordinary web sign-in.
Remediation and Detection After Suspected Abuse
When this attack is suspected, the priority is to revoke the affected tokens, invalidate sessions where possible, and confirm whether refresh tokens or downstream API access were issued. Review sign-in logs, consent logs, and token issuance records for unusual origin, timing, or user-agent patterns.
Detection also benefits from checking for suspicious redirect behaviour, abnormal consent prompts, and follow-on access from unfamiliar IP addresses or applications. The CoPhish OAuth phishing via Copilot Studio write-up is a useful example of how token theft can be chained from a trusted-looking front end.
Post-incident review should ask whether the stolen code was enough to mint refresh tokens, whether token binding or sender-constrained controls were present, and whether the client registration allowed an overly broad redirect pattern. If the incident exposed reusable credentials or service access, rotate the affected secrets as part of recovery.
Risk and Threat Considerations
Authorization code phishing is especially risky because it converts a momentary user deception into durable token theft. The attacker’s goal is often persistence, not just a one-time login, so the downstream impact can outlast the original phishing page or session.
Failure mechanism: The victim completes a legitimate-looking login or consent flow, the attacker captures the code during the redirect step, and the code is redeemed before it expires or is otherwise rendered unusable.
Impact: The attacker can obtain access and refresh tokens, impersonate the user or application, and move into API access, data exposure, or further lateral abuse until the tokens are revoked.
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 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS 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 code flow security is central to this attack. |
| Recommendation — Verify redirect handling, consent flow integrity, and token exchange protections for OAuth and OIDC. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token and secret handling are directly implicated when codes are redeemed for tokens. |
| IA-9 — Service Identification and Authentication | OAuth clients and protected APIs rely on authenticated service interactions in this flow. | |
| AC-3 — Access Enforcement | The attack seeks unauthorized access by turning a code into API privileges. | |
| Recommendation — Manage token and authenticator lifecycle to limit reuse after code theft. Authenticate service-to-service exchanges so stolen codes cannot be redeemed by arbitrary parties. Enforce access decisions so token-bearing sessions cannot exceed intended scope. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The attacker abuses a compromised authorization step to obtain valid tokens. |
| Recommendation — Harden API authentication paths so stolen login artifacts cannot mint usable tokens. | ||
| MITRE ATT&CK | T1566 — Phishing | The code theft begins with social engineering and credential-capture style deception. |
| Recommendation — Map phishing indicators to T1566 and hunt for lookalike login and redirect abuse. | ||
Practitioner Guidance
Why practitioners should care: This attack is a reminder that authentication UX is part of the security boundary. If users cannot reliably distinguish the real authorization flow from a spoofed one, the protocol’s trust assumptions can be bypassed without breaking crypto.
What to watch for: Treat unexpected redirects, consent screens, and code delivery paths as security events, especially when the application is high-value or the resulting tokens unlock sensitive APIs. In practice, the safest posture is to make code exchange harder to abuse than browser-visible interaction.
Practitioner takeaway: Reduce reliance on user recognition alone, and make token redemption, redirect handling, and application consent as tightly bounded as the business flow allows.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org