The server can no longer prove that the caller who presents a valid access token is the same principal that owns the PoP context. That breaks the authorization chain and lets an attacker combine token material across identities, which can turn local access into tenant-level management access.
How broken token pairing breaks the authorization chain
When Azure WAC accepts a token pair without proving both tokens belong to the same user, it stops treating the pair as one security context. That is not a small implementation bug, it changes the trust model: the server can authenticate one artifact and authorise against another, so possession of valid token material becomes enough to cross a boundary that should have remained bound to a single principal.
That is why sender-constrained designs exist. A token pair only has security value if the binding between the bearer token and the proof-of-possession context is checked at validation time, not assumed upstream. If that binding is lost, the server can be tricked into treating mixed identity material as if it were a coherent session.
This is especially dangerous in delegated or federated flows, where multiple token artifacts may already exist for a user, a client, or an intermediate service. The failure is not simply “bad token acceptance”, it is failure to preserve principal continuity across the chain of custody.
What an attacker gains from mixing token material across identities
An attacker who can recombine token material across identities can often turn a local foothold into broader access because the validation logic is no longer checking that the proof key and the access token were issued for the same subject. In practice, that can let a stolen or replayed artifact inherit privileges it should never have had, especially where management APIs or administrative portals trust the token pair as a whole.
The security break is not limited to one endpoint. Once the server accepts mismatched material, every downstream authorisation decision built on that acceptance inherits the same flaw. That makes privilege escalation and cross-tenant abuse plausible even if individual tokens look valid in isolation.
For readers who want the underlying token-security pattern, the relevant control question is whether the token is merely valid or actually bound to the holder and audience it was issued for. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession captures the sender-constraining idea, and RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens shows the same binding principle with certificates.
Where this shows up in real systems
This kind of flaw tends to appear in systems that combine access tokens, proof-of-possession artefacts, and session or client context during a single request. It becomes more severe when the platform sits at a control plane boundary, because control planes usually trust token validation as the gate to high-impact actions.
Azure WAC is a good example of why the issue matters operationally: once a management surface can be reached with mixed token material, the attacker is no longer trying to break the cryptography of the tokens themselves. They only need the server to accept an invalid pairing and then to act on the more privileged side of that pairing.
Token exchange and delegation flows raise the bar further. If a platform supports on-behalf-of, impersonation, or delegated access, then validation must be explicit about which identity is acting, which identity is being represented, and whether the proof mechanism matches the subject of the access token. See RFC 8693: OAuth 2.0 Token Exchange for the delegation model, and RFC 9700: Best Current Practice for OAuth 2.0 Security for broader hardening guidance around token abuse and sender-constrained tokens.
Risk and Threat Considerations
Broken token binding creates a privilege-escalation path because the server can be induced to trust a hybrid security context that no legitimate session ever produced. The practical risk is cross-identity confusion, where one user’s valid token material is enough to activate another user’s proof context and unlock higher-value management actions.
Failure mechanism: The validation layer fails to prove that the access token and the proof-of-possession context were issued for the same principal, so mixed token material is accepted as if it were a legitimate bound pair.
Impact: Attackers can combine stolen or replayed token material across identities, break the authorization chain, and in the worst case move from limited local access to tenant-level management access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Broken token binding is an authentication failure for API-style token validation. |
| Recommendation — Enforce binding checks so mixed token material cannot authenticate as one session. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The issue is a failure to authenticate the same user across token artifacts. |
| IA-5 — Authenticator Management | Token pairs and proof material must be issued, validated, and revoked as linked authenticators. | |
| IA-9 — Service Identification and Authentication | The scenario involves proof-of-possession and token-based service-to-service style validation. | |
| Recommendation — Require authentication logic to verify that both token artifacts map to the same user. Bind, rotate, and revoke token material together so invalid pairings cannot be accepted. Validate service-token binding so the caller cannot swap identity context across tokens. | ||
Practitioner Guidance
What to verify: Confirm that token validation enforces principal continuity, audience restriction, and holder binding at the same point in the request path. If the server accepts each artifact independently, treat that as a design defect, not a hardening gap.
Decision rule: If any management action can be authorized by a token pair that was not cryptographically and logically bound to the same user, block deployment until the binding check is enforced and regression-tested.
What good looks like: A valid access token is useless unless the matching proof context, client, and subject relationship all line up. At that point, the server is validating one security story, not stitching together two unrelated ones.
Practitioner takeaway: The important control is not token validity alone, it is token coherence, the platform must prove that every accepted pair represents one and only one principal end to end.
Related resources from NHI Mgmt Group
- What breaks when a security management service and its user interface share the same runtime in Azure?
- How should organizations respond to OAuth token abuse incidents?
- How should teams respond when a service account token is exposed?
- What breaks when token validation is treated as the same thing as authorisation?