Scope escalation through delegation

How it works

Modern service architectures pass identity forward through multiple hops: a user authenticates to a front-end, the front-end calls a backend on the user's behalf, and the backend may call a further service down the chain. Token exchange (RFC 8693) exists to make this safe by letting each hop swap a broad token for a narrower one scoped to only what the next call needs, so a compromise of one downstream service cannot reach further than its own scope.

Scope escalation happens when a service in that chain does not enforce the narrowing it is supposed to perform. A backend that forwards the scope a caller requests, rather than the scope its own policy allows for that caller, will issue a token with more authority than the original delegation intended. An attacker who controls or compromises one link in the chain can then request a token scoped far beyond what their position in the chain should permit, and the identity provider issuing the downstream token has no way to know the request came from a caller trying to widen its own authority rather than narrow it.

Why it works

The security of a delegation chain depends on every hop enforcing least privilege on the way out, not just the identity provider enforcing it on the way in. The control assumption that fails is that scope-narrowing is a property of the protocol; it is only a property of the protocol if every service that issues an exchanged token actually checks the requester's entitlement against the requested scope before issuing it. OAuth defines the mechanism for exchange but does not mandate how a given service decides what a caller is allowed to ask for, so that decision is implemented separately by each service, and a service that skips the check turns delegation into unrestricted impersonation.

How to detect it

• A token issued through exchange carrying a broader scope than the calling service has ever requested for other users or contexts.
• Token exchange requests from a downstream service asking for scopes outside the range that service's documented function requires.
• A spike in exchange volume from a single service identity, which can indicate automated probing for scopes a misconfigured policy will grant.

Be honest about the limits: legitimate services occasionally need a wider scope for a new feature, and a one-time change in requested scope is not by itself suspicious. This needs a baseline of normal scope requests per service before a deviation means anything, and even then the signal is a request pattern, not proof of intent.

How to stop it

• Enforce scope allowlists per service identity at the token exchange endpoint, so a caller can never receive more authority than its own registered policy permits, regardless of what it asks for.
• Log every exchange decision including the requested scope and the granted scope, so a narrowing failure is visible in the token issuance record rather than only in downstream API logs.
• Treat each service in a delegation chain as its own trust boundary and apply privilege escalation analysis to the chain as a whole, not just to the initial user authentication.
• Set short lifetimes on exchanged tokens so a scope that slipped through has a narrow window of use before it expires.
• Review delegation architecture during design, not after incident, since the failure mode is a missing check rather than a bug that surfaces obviously in testing.

Seen in the wild

No public breach has been attributed to this exact failure mode by name. It is documented here because the mechanism, a missing scope check at one hop in a multi-service delegation chain, is the generalized version of the cross-tenant token confusion bug HashiCorp patched in its Terraform MCP Server, and the pattern recurs anywhere a broker service sits between a user and a privileged API.

Sources

• RFC 8693: OAuth 2.0 Token Exchange