LLM Authentication Attacks: OAuth Token Theft, Session Hijacking, and Identity Bypass in AI Platforms

OAuth token replay, CSRF bypass, scope escalation, IDOR in agent workspaces, and cross-user identity hijacking are the authentication attack classes that compromise AI platforms at the identity layer. These attacks do not target the model. They target the authentication and authorization infrastructure that controls who can access what. The model is the entry point; the identity system is the prize. Backed by disclosed vulnerabilities in MCP OAuth flows, Langflow IDOR, and Open WebUI authorization bypasses, here is the full threat map and the defense architecture that closes the gaps.

Why authentication attacks in LLM platforms are different

Most LLM security discussion focuses on prompt injection, context poisoning, and output exfiltration. These are model-layer attacks: they manipulate what the model reads or produces. Authentication attacks are different. They target the infrastructure that authenticates users, authorizes tool calls, and manages sessions around the model. The model never sees the attack. The model is not the vulnerability. The authentication and authorization layer is.

LLM platforms have a uniquely broad authentication surface. A single AI assistant may authenticate to email providers, cloud storage services, databases, internal APIs, and MCP servers, all through different OAuth flows, API keys, and session tokens. Each authentication path is a potential attack vector. Each token is a potential credential that an attacker can steal, replay, or escalate.

The OWASP LLM Top 10 classifies these attacks under LLM06 (Excessive Agency) and LLM07 (System Prompt Leakage), but the full scope of authentication attacks in LLM platforms cuts across at least four categories: LLM01 (Prompt Injection), LLM02 (Sensitive Information Disclosure), LLM06 (Excessive Agency), and LLM07. An attacker who compromises an OAuth token can inject instructions through tool descriptions, exfiltrate data through authorized tool calls, and escalate privileges across tenant boundaries, all without ever touching the user prompt.

Six authentication attack families

1. OAuth token replay and theft

MCP servers authenticate to external services using OAuth tokens. These tokens grant access to Gmail, Google Drive, Slack, GitHub, and any service the agent needs. The attack surface is straightforward: if an attacker can obtain the OAuth token, they can replay it to access the same services with the same permissions, without the user's knowledge.

GHSA-8jr5-6gvj-rfpf disclosed that some MCP server implementations expose OAuth tokens in server logs, error messages, and SSE event payloads. An attacker who can read server logs or intercept SSE traffic obtains a valid OAuth token that grants access to the user's connected services.

mcp_oauth_token_replay (high) detects patterns where OAuth tokens are exposed, logged, or transmitted in ways that allow replay. The detection covers tokens in URLs, headers, and SSE events.

The token replay attack is particularly dangerous in multi-server MCP architectures. A compromised MCP server that holds OAuth tokens for Gmail can replay those tokens from a different server context, accessing the user's email without the original authorization flow. The user sees the MCP server acting on their behalf. They do not see that the token was obtained from a different server that the user never authorized to access their email.

2. OAuth CSRF and state bypass

OAuth flows use a state parameter to prevent cross-site request forgery. The client generates a random state value, includes it in the authorization request, and verifies it in the callback. If the state parameter is missing, predictable, or not validated, an attacker can forge the callback and hijack the authorization code.

mcp_oauth_csrf_bypass (high) detects MCP OAuth flows that lack CSRF state parameters, use predictable state values, or accept callbacks without state validation. The attack works like this:

1. The attacker initiates an OAuth flow with a legitimate MCP server, obtaining a valid authorization code bound to their account.
2. The attacker crafts a callback URL with the authorization code and sends it to the victim.
3. The victim's MCP server processes the callback, exchanging the attacker's authorization code for a token that is now associated with the victim's session.
4. The attacker can now access the MCP server as the victim, using the token that was bound to the victim's session.

This is not theoretical. Multiple MCP server implementations have been found to omit the state parameter entirely or accept any state value in the callback. The vulnerability is a design-level flaw in the OAuth implementation, not a configuration error.

3. OAuth scope escalation

OAuth scopes define what permissions the user has granted. A token with read scope should not be able to perform write operations. But in practice, many MCP server implementations do not enforce scope boundaries rigorously.

ta_oauth_scope_escalation (high) detects attempts to use an OAuth token beyond its authorized scope. mcp_attacks_oauth_scope_bypass (high) catches MCP-specific OAuth scope bypass patterns where the server accepts a token with limited scopes but allows operations that require broader permissions.

The escalation can happen in two directions. Vertical escalation uses a read-only token to perform write operations. Horizontal escalation uses a token scoped to one resource (the user's own calendar) to access another resource (a colleague's calendar). Both are enabled by MCP servers that validate the token's authenticity but not its scope boundaries.

4. Cross-server identity hijacking

MCP architectures often run multiple servers, each with its own authentication context. The mcp_oauth_untrusted_server_rce (critical) rule detects a particularly severe attack: an untrusted MCP server that obtains the user's OAuth identity and uses it to execute code or access resources on a different, trusted server.

mcp_oauth_cross_user_identity (high) detects patterns where one MCP server's OAuth identity is used to authenticate to a different server under a different user context. This is a cross-user identity attack: the attacker compromises one MCP server, extracts its OAuth identity, and replays that identity against a different server where the original user has access.

The attack exploits a fundamental trust assumption in MCP architectures: that each server's authentication context is isolated from every other server's. In practice, OAuth tokens issued for one server can be replayed against another server if they share the same authorization server. The victim authorized Server A to read their calendar. The attacker uses Server A's token to authenticate to Server B, which the user also authorized, and now the attacker has access to both services.

5. IDOR and BOLA in agent workspaces

Insecure Direct Object Reference (IDOR) and Broken Object-Level Authorization (BOLA) are well-known in traditional web application security. In LLM platforms, they take a more dangerous form because the agent can be instructed to access resources that the user never intended to share.

ta_workspace_idor_role_escalation (high) detects attempts to access workspace resources with escalated roles. de_workspace_idor_access (high) catches data exfiltration through workspace IDOR. ta_praisonai_idor (high) targets IDOR in specific agent frameworks.

The Langflow IDOR vulnerabilities documented in GHSA-qrpv-q767-xqq2 and GHSA-9c59-2mvc-vfr8 are instructive. An authenticated user could execute another user's flow by specifying the victim's flow ID. The authorization check simply did not exist. In an LLM platform, this means a user can instruct the agent to run another user's workflows, access their data, and perform actions on their behalf, all through a tool call that the platform authorizes without checking ownership.

The attack is even more dangerous in multi-tenant SaaS platforms. A user in Tenant A can potentially access Tenant B's data through IDOR in the agent's tool calls, if the platform does not enforce tenant boundaries at every layer.

6. OAuth redirect and SSRF through profile URLs

OAuth profile picture URLs are a well-documented SSRF vector in LLM platforms. GHSA-226f-f24g-524w disclosed that Open WebUI's _process_picture_url function validates the initial URL but follows up to 10 redirects without re-validating. An attacker submits a URL that passes validation but redirects to an internal address.

mcp_oauth_js_scheme_redirect (high) detects OAuth redirect flows that use JavaScript URI schemes, which can execute arbitrary code in the browser context. mcp_oauth_ssrf_internal (high) catches MCP OAuth flows that redirect to internal network addresses, enabling SSRF attacks that bypass network boundaries.

oauth_ssrf_redirect_token_exfiltration (high) detects a particularly dangerous variant: the attacker manipulates the OAuth callback URL to redirect the authorization code to their own server, combining SSRF with token theft. The user completes the OAuth flow, the authorization code is sent to the attacker's server, and the attacker exchanges it for a valid access token.

Why the authentication layer breaks in AI platforms

Authentication in LLM platforms has three properties that traditional web applications do not have, and each one creates new attack surfaces.

• Delegated authority. The AI agent authenticates to external services on the user's behalf. The user authorizes the agent through an OAuth flow, and the agent holds the resulting token. If the token is compromised, the attacker gains all the permissions the user granted, not just the permissions the user intended for the current task.
• Multi-server composition. MCP architectures compose multiple servers, each with its own authentication context. A single agent may hold tokens for Gmail, Slack, Google Drive, and an internal database simultaneously. A compromise in any one server can cascade across all connected services through token replay and identity hijacking.
• Agent-initiated tool calls. The model decides when and how to use authenticated tools. A prompt injection that convinces the model to call a tool with escalated scopes does not need to bypass authentication. It needs to convince the model to use the authentication it already has in a way the user did not intend. This is excessive agency (OWASP LLM06) at the authentication layer.

The combination means that a single OAuth token compromise can give an attacker access to every service the agent is connected to, with no additional authentication required.

Defense architecture

Securing authentication in LLM platforms requires controls at five layers. None of them are optional.

1. Token isolation and scope enforcement

Every OAuth token must be scoped to the minimum permissions required for the current task. A token that grants read access to the user's calendar should not also grant write access to their email.

• Per-server token isolation. Tokens issued for one MCP server must not be replayable against another. Each server gets its own OAuth client ID and secret, and the authorization server enforces audience restrictions.
• Scope validation at every tool call. Before the agent invokes a tool, validate that the token's scopes cover the requested operation. A read-only token cannot be used for a write operation, regardless of what the model decides to call.
• Token binding. Bind each token to the specific MCP server, user session, and tool call scope. A token extracted from one context should not be valid in another.

2. OAuth CSRF and state validation

Every OAuth flow must include a cryptographically random state parameter, and the callback must validate it before exchanging the authorization code for a token.

• Random state generation. The state parameter must be at least 128 bits of cryptographically random data. Predictable or missing state values are a direct path to CSRF.
• State validation in the callback. The callback handler must verify that the state parameter in the response matches the state parameter that was sent in the authorization request. No exceptions.
• PKCE (Proof Key for Code Exchange). Use PKCE for public clients (like MCP servers running on user machines). PKCE adds a code verifier/challenge pair that prevents authorization code interception even if the state parameter is bypassed.

3. Redirect URL validation

Every URL that the platform fetches on behalf of the user must be validated before the request is made, and redirects must be re-validated at each hop.

• Initial URL validation. Check the scheme, domain, and path against an allowlist. Block internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16) and cloud metadata endpoints (169.254.169.254).
• Redirect chain validation. Do not follow redirects automatically. Validate each redirect URL against the same allowlist before following it. A URL that starts at a legitimate domain but redirects to an internal address is a classic SSRF vector.
• JavaScript URI scheme blocking. Reject URLs with javascript:, data:, and vbscript: schemes. These can execute arbitrary code in the browser context.

4. Authorization enforcement at every layer

The authentication layer confirms who the user is. The authorization layer confirms what they are allowed to do. Both must be enforced at every API endpoint, every tool call, and every cross-server interaction.

• Object-level authorization. Every API endpoint must verify that the authenticated user owns or has access to the requested resource. The IDOR vulnerabilities in Langflow (GHSA-qrpv-q767-xqq2, GHSA-9c59-2mvc-vfr8) demonstrate what happens when this check is missing.
• Tenant isolation. In multi-tenant platforms, every request must be validated against the user's tenant context. A request from Tenant A must never access Tenant B's data, regardless of the user's role or permissions within their own tenant.
• Role-based access control. Every tool call must respect the user's role. An agent that has been granted read-only access to a resource must not be able to perform write operations through that same access path.

5. Monitoring, anomaly detection, and token lifecycle

Authentication attacks leave traces in logs, token usage patterns, and access histories. The monitoring layer catches attacks that slip through the preventive controls.

• Token usage monitoring. Track when, where, and how each OAuth token is used. A token that is used from a different IP, a different user agent, or a different MCP server than expected is a strong signal of replay.
• Scope escalation alerts. Alert when a token is used for operations outside its authorized scope. Even if the authorization layer blocks the operation, the attempt itself is a signal of an attack in progress.
• Cross-server identity correlation. Monitor for OAuth identities that appear across multiple MCP servers in patterns that suggest token replay or identity hijacking.
• Token rotation. Rotate OAuth tokens on a schedule, not just on compromise. Short-lived tokens with automatic rotation reduce the window of exposure for replay attacks.

How Context Guard detects authentication attacks

Context Guard runs as a reverse proxy in front of your LLM provider. Every prompt, including OAuth token references, authentication parameters, and tool call arguments, flows through the detection pipeline before it reaches the model. The ruleset includes authentication-specific detection patterns targeting all six attack families:

• mcp_oauth_token_replay (high) — OAuth token exposure, logging, and replay patterns
• mcp_oauth_csrf_bypass (high) — missing or invalid CSRF state in OAuth callbacks
• ta_oauth_scope_escalation (high) — attempts to use tokens beyond authorized scope
• mcp_attacks_oauth_scope_bypass (high) — MCP-specific OAuth scope bypass patterns
• mcp_oauth_untrusted_server_rce (critical) — untrusted MCP server obtaining user identity
• mcp_oauth_cross_user_identity (high) — cross-user identity hijacking through OAuth
• ta_oauth_session_hijack (high) — session token theft and replay
• oauth_ssrf_redirect_token_exfiltration (high) — OAuth redirect manipulation for SSRF and token theft
• mcp_oauth_js_scheme_redirect (high) — JavaScript URI scheme in OAuth redirects
• mcp_oauth_ssrf_internal (high) — OAuth flows redirecting to internal network addresses
• ta_workspace_idor_role_escalation (high) — workspace IDOR with role escalation
• de_workspace_idor_access (high) — data exfiltration through workspace IDOR
• ta_praisonai_idor (high) — IDOR in specific agent frameworks
• idor_agent_cross_workspace (high) — cross-workspace IDOR in agent platforms
• ta_mcp_csrf_oauth_callback (high) — CSRF in MCP OAuth callbacks
• mcp_client_rce_oauth_redirect (high) — RCE through MCP client OAuth redirect
• dos_mcp_oauth_registration (medium) — DoS through MCP OAuth registration abuse

These 17 rules join the broader detection library covering prompt injection, encoding tricks, data exfiltration, and output filtering. Every rule carries an OWASP reference so your compliance team can map every event to the framework without manual work.

LLM authentication security checklist

Before deploying an MCP-connected agent or LLM platform to production, verify every item on this list:

• Every OAuth flow includes a cryptographically random state parameter that is validated in the callback.
• PKCE is used for all public clients (MCP servers, browser-based agents, mobile apps).
• OAuth tokens are scoped to the minimum permissions required for each tool call.
• Scope boundaries are enforced at every API endpoint, not just at the OAuth authorization server.
• Tokens are bound to the specific MCP server, user session, and tool scope that requested them.
• Token replay across servers is prevented by audience restrictions and token binding.
• Redirect URLs are validated against an allowlist at every hop, not just the initial URL.
• JavaScript URI schemes are blocked in all OAuth redirect and profile picture URL processing.
• Object-level authorization is enforced at every API endpoint. No endpoint accepts a resource ID without verifying ownership.
• Tenant isolation is enforced at every layer. Cross-tenant access is blocked by default.
• Tool call arguments are validated against the authenticated user's scope before execution.
• OAuth token usage is monitored for replay, scope escalation, and cross-server identity anomalies.
• Tokens are rotated on a schedule, not just on compromise. Short-lived tokens reduce the replay window.
• Every MCP server connection, disconnection, and tool invocation is logged with a stable request ID for incident investigation.
• OWASP LLM06 (Excessive Agency) and LLM07 (System Prompt Leakage) coverage is documented for every MCP integration.

If you are running MCP-connected agents in production and any of these are missing, you have an authentication gap that an attacker can exploit today. The security page has the full architecture. The free trial has the product.