---
title: Cross-Service Token Attack
url: https://www.emergentmind.com/topics/cross-service-token-attack
type: topic
---

# Cross-Service Token Attack

Cross-service token attack denotes a family of failures in which an authentication artifact, session artifact, capability, or token-like control object established in one security context is accepted, replayed, reinterpreted, or exploited in another. Across the surveyed literature, the “cross” boundary varies: between relying parties in WebAuthn, between OpenID Connect endpoints, between 5G network functions, between an Android app and an embedded WebView, between local applications and mobile SDK services, between devices, between agent and tool servers, and between bridge components spanning multiple chains. This synthesis suggests that the unifying issue is not a single protocol bug, but insufficient binding of a token or token-like artifact to its intended service, presenter, device, or execution path [2205.08071] [1508.04324] [2509.08992] [2603.02539] [2604.24341].

## 1. Definition and terminological scope

The literature uses the topic unevenly. Some works are direct instances of cross-service token attack in a narrow sense. In FIDO2/WebAuthn, timing differences in key-handle processing allow an adversary to link a user’s accounts on multiple services even though the protocol is designed to use a different credential per service [2205.08071]. In OpenID Connect, “Malicious Endpoints” attacks cause a client to send authorization codes, access tokens, and client credentials to the wrong service after Discovery and Dynamic Registration metadata is maliciously supplied [1508.04324]. In 5G SBA, the paper explicitly names a “Cross-Service Token Attack” in which a token legitimately issued for one SBI service is accepted by another because scope validation is broken in free5GC [2509.08992].

Other papers are adjacent but still informative. The Android WebView work is best understood as session/cookie reuse across the app–WebView boundary rather than a classic federated-token attack: the remote site “authenticates the WebView and not the application,” which allows the host app to drive authenticated requests or replay cookies [1411.3124]. The Apple Intelligence work demonstrates a practical cross-device replay of TGTs and OTTs, not a direct proof that the same token is accepted across multiple distinct backend services; its relevance is that non-transferability fails when tokens are not bound to the rightful device [2604.15637]. TULIP, by contrast, is not a treatment of stolen SAML assertions, OIDC bearer tokens, or RP session cookies; it is a pre-authentication gate that requires an enrollment JWT cookie before the IdP login page is rendered [2401.11599].

A further complication is that “token” is overloaded. In identity, mobile, telecom, and bridge systems, it denotes cookies, JWTs, authorization codes, access tokens, proofs, key handles, or transferable IPC objects. In recent LLM-agent security work, it can instead denote model-generation tokens and token budgets. The agent-tool paper on “resource amplification via tool-calling chains” is therefore a cross-service token attack in an economic sense: one service causes another to spend excessive tokens across turns while preserving protocol compatibility and final-task correctness [2601.10955].

## 2. Core failure modes

A recurring failure mode is broken audience, scope, or endpoint binding. In OpenID Connect, attacker-controlled Discovery metadata can split one logical OP across different services, so that registration and authorization occur at an honest OP while the token and userinfo endpoints point to `malicious.com`; the client then sends the code, `client_id`, and `client_secret` to the malicious token endpoint, or sends a fresh `access_token` to a malicious `userInfoEndp` [1508.04324]. In free5GC, a token issued for `nudr-dr` can be reused against `nnrf-disc` because `VerifyOAuth` calls `verifyScope(...)` but returns `errors.Wrapf(nil, ...)` when the scope check fails, so unauthorized NF operations are accepted [2509.08992].

A second failure mode is provenance confusion: the system authenticates origin rather than current presenter. The Android SDK paper shows that `PendingIntent.getCreatorPackage()` identifies who created a `PendingIntent` but cannot attest who presents it. An attacker with `NotificationListenerService` access can steal a legitimate partner’s `PendingIntent` from a notification and replay it to the provider service, which then authenticates the attacker as the partner. The attack succeeds against both mutable and immutable `PendingIntent`s because immutability protects contents, not provenance [2603.02539].

A third failure mode is insufficient non-transferability. The Apple Intelligence study reconstructs a two-stage design with long-lived TGTs and shorter-lived OTTs, then shows that those tokens can be extracted from keychain storage and replayed on another Mac. The TGT remains useful for several days, OTTs for about 12 hours, and the attacker’s use is rate-limited against the victim. The paper’s main lesson is explicit: anonymizing identity does not by itself make the service secure; non-transferability requires cryptographic binding to the rightful user or device [2604.15637].

A fourth failure mode is side-channel correlation rather than direct replay. FIDO2/WebAuthn uses unique key pairs per service, yet vulnerable authenticators process “wrong service but correct authenticator” handles measurably differently from “wrong authenticator” handles. Because browsers perform silent authentications over `allowCredentials`, an attacker can compare total execution times and link accounts across relying parties without stealing private keys or breaking signatures [2205.08071].

A fifth failure mode is ambient delegated authority and confused-deputy behavior. In MCP ecosystems, a malicious weather server can induce an AI client to discover and invoke a legitimate banking tool authenticated through OAuth2, retrieve the user’s account balance, and then send it to an attacker-controlled endpoint. The proof of concept exfiltrates sensitive data rather than the token itself, but the authority of the already-authenticated tool is reused across services through a shared orchestrator [2507.19880].

## 3. Representative architectures and attack patterns

Representative cases span web identity, mobile platforms, telecom control planes, agentic systems, and bridge protocols [2205.08071] [1508.04324] [1411.3124] [2603.02539] [2509.08992] [2604.15637] [2507.19880] [2312.12573].

| Domain | Artifact or control object | Representative mechanism |
|---|---|---|
| FIDO2/WebAuthn | key handle / credential ID | timing-based account linking across relying parties |
| OpenID Connect | authorization code, `access_token`, `client_secret` | Discovery and Dynamic Registration redirect secrets to malicious endpoints |
| Android WebView | session cookie / session ID | app drives authenticated requests or replays cookies via `HttpClient` |
| Android cross-app SDKs | `PendingIntent` | creator/presenter confusion enables partner impersonation |
| 5G SBA | OAuth access token | token for one SBI service accepted by another NF service |
| Apple Intelligence | TGT and OTT | stolen tokens replayed on another device |
| MCP tool ecosystems | delegated OAuth context / tool authority | malicious tool induces use of another tool’s authenticated capability |
| Cross-chain bridges | proofs, messages, events, signatures | forged, replayed, or misparsed cross-domain token transitions |

In the Android WebView setting, the paper presents both browser-mediated and app-mediated variants. The host app can use `WebView.loadUrl`, `WebView.loadData`, or `WebView.postUrl` to issue authenticated requests inside the WebView session, or it can call `CookieManager.getCookie(url)` and then replay the cookie via `httpPost.setHeader("Cookie", cookie)` in a raw `HttpClient` request [1411.3124]. In Apple’s XARA work, related cross-app resource access can steal an iCloud token, the Evernote authentication token, the Pushbullet secret token, or browser-stored credentials by abusing keychain items, URL schemes, `NSConnection`, WebSocket endpoints, or Bundle ID confusion [1505.06836].

In bridge systems, the cross-service boundary is the chain boundary. The SoK on cross-chain bridges describes lock-and-mint and liquidity-pool-based communication models, then catalogs attack vectors such as problematic mint, fake burn, incorrect release, replayed withdraw, incorrect event emission, and fake event emission. These attacks violate the integrity of token movement between services or chains: unbacked wrapped assets can be minted, locked assets can be released without a valid burn, and proofs or events can be replayed or forged [2312.12573].

This suggests a common abstraction: the artifact being misused need not be an OAuth bearer token. It may be a key handle, JWT, cookie, proof, validator signature set, one-time token, `PendingIntent`, or even a service-produced instruction channel whose outputs another service obeys.

## 4. Attack mechanics and validation blind spots

Many attacks follow a two-stage or multi-stage structure. The OpenID Connect paper explicitly frames its contribution as a class of second-order vulnerabilities: first, attacker-supplied endpoint metadata is stored by the client through Discovery; later, the stored values are reused in security-critical operations such as token redemption or userinfo retrieval [1508.04324]. The WebView paper has the same temporal structure in simpler form: the user first authenticates to the trusted site inside WebView, then the host app reuses the resulting session cookie or session ID to send forged requests [1411.3124].

Extraction or observability is often local rather than cryptographic. On Android, `NotificationListenerService` exposes `contentIntent`, action intents, and delete intents from posted notifications, which is sufficient to steal a legitimate partner’s `PendingIntent` for later replay [2603.02539]. On Apple Intelligence, the reverse-engineered token path ultimately reaches `SecItemCopyMatching`, and the paper shows that token payloads can also be read with `/usr/bin/security`; the actual token bytes are recovered from the returned plist [2604.15637]. In WebAuthn, no token is extracted at all; instead, the browser’s silent processing of `allowCredentials` becomes a timing oracle [2205.08071].

Acceptance typically hinges on a server-side blind spot. In the WebView case, the remote service authenticates based on session cookies and cannot distinguish the host app from the browser-like context that already holds the authenticated state [1411.3124]. In free5GC, the producer NF performs JWT parsing but fails to reject mismatched scope, so “an access token with an arbitrary scope field value will be accepted by an arbitrary NF” [2509.08992]. In the PendingIntent case, the provider service upgrades “creator package” into proof of present caller identity, even though the token is transferable [2603.02539]. In bridge exploits, the blind spots are proof uniqueness, validator trust, event origin, or missing accounting constraints; the SoK’s “replayed / unlimited withdraw” class is the most literal example of a reusable authorization artifact that was not consumed exactly once [2312.12573].

Agentic systems add a distinct blind spot: validation is often attached to final answers or API compatibility rather than to the entire execution trajectory. The tool-layer economic DoS paper keeps the final payload correct and function signatures unchanged, yet expands a task into trajectories exceeding 60,000 tokens, inflates costs by up to 658x, raises energy by 100–560x, drives GPU KV cache occupancy from less than 1% to 35–74%, and cuts co-running throughput by approximately 50% [2601.10955]. The malicious MCP server paper makes the same architectural point for authority rather than cost: the dangerous step is not direct server-to-server compromise, but orchestrator-mediated data flow across tools [2507.19880].

## 5. Defensive principles and verification strategies

The dominant defensive principle is stronger binding between artifact and authorized context. In OpenID Connect, the proposed mitigations include OP whitelisting, endpoint restrictions, and binding Discovery to the later authentication response through issuer validation, so that a malicious Discovery service cannot mix `authEndp` from one service with `tokenEndp` from another [1508.04324]. In Android SDK ecosystems, the paper’s defense replaces transferable `PendingIntent`-based authentication with Bound Service IPC authenticated by `Binder.getCallingUid()`, augmented by signer certificate verification and server-side certificate-hash validation [2603.02539]. In Apple Intelligence, the paper argues that non-transferability requires cryptographic binding to the rightful user or device, and discusses sender-constrained or hardware-bound designs as the natural direction [2604.15637].

Timing, replay, and amplification channels require separate controls. For FIDO2, the strongest authenticator-side fix is constant-time key-handle processing so that “wrong token,” “wrong RP,” and “correct RP” paths do not diverge measurably. The paper also discusses a KDF-based non-resident-key design and notes browser-side mitigations such as deduplicating `allowCredentials`, adding random delays to silent failures, and limiting the list size; Chromium adopted deduplication plus a limit of 64 key handles under CVE-2021-38022 [2205.08071]. For bridges, the verification framework in GoAT-X elevates `ValidProof(M,signature)`, `NonceUnused(chain,nonce)`, `LockedCorrect(sender,token,amount)`, and `UnlockedCorrect(receiver,token,amount)` into explicit predicates, then reports 92% recall on fine-grained audit points, 95% coverage of vulnerable projects, and 117 confirmed risks in the wild [2604.24341].

Composition-heavy systems need isolation and trajectory-aware controls. The MCP trojan paper recommends capability-based permissions, mandatory access boundaries, and the ability to designate servers as sensitive with restricted interoperability [2507.19880]. The tool-layer resource-amplification paper argues for a shift “from validating final answers to monitoring the economic and computational cost of the entire agentic process,” and specifically implies per-session token budgets, chain-length controls, tool-response sanitization, and behavioral baselines for normal tool-calling patterns [2601.10955]. By contrast, the WebView paper is diagnostically strong but weak on concrete defenses; it states that the attacks are easy to execute, difficult to detect and prevent, and leaves solutions to future work [1411.3124].

Telecom systems require the same discipline at a different layer. The 5G SBA case makes clear that token integrity is not enough: the producer NF must actually enforce scope, audience, and service identity rather than merely parse the JWT. The paper also indicates that richer 3GPP authorization attributes, such as NF instance identity and slice constraints, need to be encoded and validated rather than ignored [2509.08992].

## 6. Misconceptions, limits, and research directions

A common misconception is that unique per-service credentials or anonymous tokens automatically prevent correlation or replay. The FIDO2 paper refutes the first point: per-service key pairs do not guarantee unlinkability if key-handle processing leaks timing structure across services [2205.08071]. The Apple Intelligence paper refutes the second: anonymized TGTs and OTTs do not guarantee security when tokens are locally retrievable and not sender-constrained [2604.15637].

Another misconception is that every attack in this area is a strict service-to-service bearer-token replay. Several important works are only partially on target. The Android WebView attack targets the same remote site that authenticated the user; it is therefore more precisely “session/cookie reuse via embedded browser context across application boundaries” than a federated cross-service replay [1411.3124]. TULIP is adjacent because it reduces the usefulness of stolen credentials and MFA bombing in SSO environments, but it does not analyze theft of access tokens, ID tokens, refresh tokens, SAML assertions, or RP session cookies, and its enrollment JWT is not RP-scoped [2401.11599]. The MCP cross-tool exfiltration paper is closer to confused-deputy authority abuse than to direct token theft, though it makes plain how already-authenticated tools can be induced to act for unrelated workflows [2507.19880].

A further misconception is that protocol compliance or correct outputs imply safety. OIDC malicious endpoints preserve nominal protocol phases while redirecting sensitive artifacts [1508.04324]. MCP-compatible tool servers can remain protocol-compatible and still drive economically catastrophic multi-turn trajectories while returning the correct final answer [2601.10955]. In cross-chain systems, the SoK and GoAT-X both show that the decisive failures are often semantic gaps—missing constraints, bypassable validations, replayable proofs, inconsistent event handling, or accounting mismatches—rather than cryptographic breaks [2312.12573] [2604.24341].

The literature therefore points toward a stable research agenda. Tokens and token-like artifacts need tighter audience and service binding, presenter authentication, and proof-of-possession properties. Failure handling must be constant-time where unlinkability is claimed. Cross-context composition needs explicit capability boundaries. Proofs, nonces, and messages must be uniquely consumed. Standards and implementations must be checked for semantic alignment rather than only for syntactic conformance. This suggests that cross-service token attack is best understood as a class of semantic trust-boundary failures: the system accepts the right artifact in the wrong place, from the wrong presenter, for the wrong service, or along the wrong execution path.

Source: https://www.emergentmind.com/topics/cross-service-token-attack