Authorization Code Injection

How authorization code injection works

Authorization code injection is a flow-level attack on OAuth-style login and consent journeys, not a weakness in the code format itself. The attacker’s goal is to cause a valid authorization code to arrive where the attacker can redeem it or bind it to the wrong browser session, so the code no longer represents the user, client, and redirect endpoint that originally obtained it.

The attack succeeds when the authorization server, client, or surrounding browser flow treats the code as a standalone artifact instead of binding it to the initiating session and redirect context. That usually means the defender has allowed a code, a state value, and the eventual token exchange to drift apart.

Why it is dangerous in OAuth and MCP flows

In OAuth and MCP settings, the authorization code is a short-lived but highly sensitive handoff. If an attacker can steer that code to an attacker-controlled endpoint, or swap it into a different session, the result can be unauthorized token issuance, account takeover, or access to a protected resource under the victim’s consent.

The danger is not only interception. It also appears when a malicious page, open redirector, weak client callback handling, or brittle browser session logic lets an injected code look legitimate enough for the client to continue the flow. The problem is especially acute when the client does not enforce exact redirect matching and strong session correlation.

For a deeper walkthrough of the surrounding OAuth hardening patterns, see the OAuth 2.0 Security Best Current Practice Guide, which covers code injection, mix-up, PKCE downgrade, and redirect URI exact matching.

What conditions make the attack possible

Authorization code injection typically depends on a weak trust boundary between the browser session, the authorization response, and the token exchange request. If the client accepts a code without checking that it belongs to the same user session that initiated the request, the attacker can sometimes reuse or substitute the value.

Three controls matter most: a strong and unpredictable state value, exact redirect URI validation, and a token exchange that is tied to the originating client and session context. If any one of these is treated as optional, the flow becomes easier to subvert.

The risk also rises when developers blur authentication, authorization, and session handling into one “works in testing” implementation. OAuth and OpenID Connect are designed to separate those steps, and the code flow becomes fragile when that separation is not preserved.

How organisations reduce exposure

Defenders should first inventory every client, redirect URI, and callback path that can complete the flow, then verify which ones are internet-facing or reachable through intermediate redirects. Exposure often hides in edge cases, such as legacy callbacks, multi-tenant apps, or brokered login paths.

Then validate the full authorization journey from browser to token endpoint, including state handling, redirect URI matching, PKCE where appropriate, and whether the client rejects any code that does not belong to the originating session. If the system uses MCP, confirm that its authorization design follows the platform’s own discovery and token audience rules rather than relying on generic OAuth assumptions.

When you need a reference for the protocol baseline, the RFC 6749: The OAuth 2.0 Authorization Framework remains the core starting point, while the Model Context Protocol: Authorization specification explains how MCP servers should handle authorization discovery and token use.

Detection, review, and response after suspected abuse

Detection usually begins with unusual authorization-code redemption patterns, mismatched user-agent or session context, repeated failed token exchanges, or redirects that do not line up with the expected callback journey. Because the attack is often brief, log quality and correlation are more important than volume.

After suspected exploitation, review whether a code was redeemed from an unexpected session, whether tokens were issued after a suspicious redirect path, and whether a compromised browser session or injected callback altered the flow. If tokens or refresh tokens may have been exposed, treat the event as an access compromise, not just a login anomaly.

For implementation detail on the client and server side, the OAuth 2.0 and OpenID Connect Guide for Identity Teams is useful for understanding the broader grant and token lifecycle, and the Open Redirect Guide shows why redirect weaknesses so often become code theft paths.

Risk and Threat Considerations

Authorization code injection is dangerous because it turns a legitimate consent flow into a confusion attack on session binding. The attacker is not breaking OAuth from outside, they are exploiting weak linkage between the code, the browser session, and the redirect target.

Failure mechanism: The flow accepts a valid code that was not issued for the same session, client state, or callback context, so the attacker can redeem or transplant it before the victim’s session is fully bound.

Impact: The attacker may obtain access tokens, impersonate the user, or complete an unauthorized login or consent sequence, especially where downstream applications trust the OAuth result without additional session checks.

Practitioner Guidance

Why practitioners should care: This is a protocol-integrity problem with direct account and session consequences, so ownership belongs with the teams that implement OAuth clients, authorization servers, and callback handling, not only with application security reviewers. The control objective is to make the code unusable outside the exact browser session that initiated it.

Common misunderstanding: Many teams assume PKCE alone closes the issue. In practice, state handling, redirect URI exact matching, session correlation, and careful callback design still matter because an attacker often abuses the surrounding flow rather than the code verifier itself.

Practitioner takeaway: Treat every authorization-code flow as a binding problem, not just a token problem, and verify that the implementation rejects any code that arrives outside the expected session and redirect context.

Related resources from NHI Mgmt Group

• How should security teams prevent code injection in modern applications?
• Why do code injection flaws matter to IAM and NHI governance?
• When does code injection become a supply chain risk?
• What is the difference between prompt injection and LLM remote code execution?