Because the attacker does not need to fake the login page. They can redirect the client to the real identity provider while quietly controlling the token exchange path. That lets them capture the client secret, authorization code, and PKCE verifier, then redeem them at the real provider. The result is a valid access token for the victim account without obvious user-visible fraud.
How a Legitimate Login Page Still Becomes an Account Takeover
The login page is not the trust boundary in this attack. The malicious MCP server can hand the client a real identity provider flow while quietly steering the token exchange behind the scenes. The user sees a normal login experience, but the attacker is positioned where secrets and authorization artifacts actually move, which is enough to turn a legitimate sign-in into a victim account compromise.
That is why this class of attack is closer to authorization-path abuse than page spoofing. If the client accepts attacker-controlled endpoints, metadata, or redirect handling, the attacker can observe or relay the sensitive exchange while the victim still completes authentication against the genuine provider.
The important distinction is that trust is being abused at the protocol and client layer, not the visual layer. A legitimate provider, valid TLS, and a normal-looking sign-in screen do not protect a client that has already been induced to send its client secret, authorization code, or PKCE verifier to the wrong place.
What Makes the Token Exchange Path So Dangerous
In an OAuth-style flow, the most valuable assets are often not the page itself but the artifacts that allow token redemption. When the attacker controls the token exchange path, they can collect the client secret, intercept the authorization code, or capture the PKCE verifier and then redeem the flow at the real provider. That produces a valid access token for the victim account without any obvious fake login prompt.
This is especially dangerous in MCP because the client may treat the server as a trusted coordinator for tool access and delegated authorization. If that trust is abused, the client can end up authenticating the attacker’s chosen path while still believing it is speaking to the intended service.
For practitioners, the core issue is not whether the login page is authentic, but whether the client can be tricked into trusting attacker-controlled authorization metadata, redirects, or exchange endpoints. Once that happens, the real identity provider can become the final issuer of a stolen token.
Why the Abuse Often Looks Normal Until the Session Is Already Lost
These attacks tend to be hard to notice because the victim often completes a valid authentication ceremony. The user may see the expected provider, approve the request, and return to the application as usual. The compromise happens in the hidden mechanics of code handling, redirect routing, and token redemption, so there may be no obvious phishing signal for the user to spot.
That makes detection depend on protocol integrity checks rather than human suspicion. Strong client registration hygiene, strict redirect validation, audience-bound tokens, and no token passthrough are the kinds of controls that shrink the attack path. The MCP authorization specification is the clearest public reference for those mechanics, because it explicitly defines the authorization model for MCP transports and forbids unsafe token handling patterns such as token passthrough: Model Context Protocol: Authorization specification.
Risk and Threat Considerations
Malicious MCP servers are attractive because they let an attacker exploit trust in the protocol flow rather than in the user interface. Once the attacker can control authorization metadata or the exchange path, account takeover can occur even when the real identity provider is used end to end.
Failure mechanism: The client follows attacker-influenced authorization or token-exchange instructions, exposes a client secret, authorization code, or PKCE verifier, and the attacker redeems those artifacts at the real provider to mint a valid token.
Impact: The attacker gets authenticated access as the victim account, which can expose downstream tools, data, and connected services without the victim seeing a forged login page.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Malicious MCP servers abuse delegated authorization and token handling in agent flows. |
| Recommendation — Bind agent/tool authorization to trusted servers and reject unsafe token exchange patterns. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The attack steals or reuses auth artifacts to mint valid tokens from the real provider. |
| Recommendation — Enforce strict auth flows and reject client-side handling that enables token theft. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP server auth flows can be redirected into unsafe token exchange and secret handling. |
| NHI-05 — Overprivileged NHI | Stolen tokens become dangerous when MCP-connected identities can do too much. | |
| NHI-07 — Long-Lived Secrets | Client secrets and related artifacts are directly exposed during the malicious exchange path. | |
| Recommendation — Require secure OAuth handling and eliminate token passthrough in MCP clients. Minimise tool and token privilege so a stolen access token has limited blast radius. Rotate and shorten credential lifetime so exposed secrets lose value quickly. | ||
Practitioner Guidance
What to verify: Treat any MCP integration as untrusted unless the client strictly validates the authorization server, redirect targets, resource indicators, and token audience. The login page being genuine is not enough if the exchange path is not.
What to prioritise: Eliminate token passthrough, lock down dynamic registration, and require the client to bind authorization to a known server identity. That is the control point that stops a malicious server from relaying legitimate provider traffic into an attacker-controlled redemption path.
What practitioners underestimate: The most dangerous failure is often not credential theft in the usual sense, but legitimate token issuance to the wrong party. Once a valid access token exists, the compromise behaves like normal authenticated use until the abuse is traced back.
Practitioner takeaway: For MCP, the security question is who controls the authorization path, not whether the sign-in screen looks real.
Related resources from NHI Mgmt Group
- Why does account takeover create risk even when the account activity looks legitimate?
- Why do malicious return URL or redirect parameter flaws create account takeover risk in federated login flows?
- Why do MCP servers create higher account takeover risk than direct application logins?
- Why does insecure identity linking create account takeover risk even when one login method is protected?
