Security teams should map the end user and the caller identity deliberately, then preserve the claim set through each hop. In federated flows, token exchange can separate the identity used to obtain credentials from the identity represented to the service. If service decisions depend on user context, maintain claim integrity across ADFS, ACS, and the service bus boundary.
Why federated token exchange can break user identity continuity
Federated access is not just about whether a token is accepted. It is about whether the service can still tell who the end user is after one credential has been exchanged for another. In Azure integration flows, that usually means preserving the user context through the federation boundary rather than letting the exchange collapse everything into a generic caller identity.
When teams design the flow correctly, the identity used to acquire credentials can differ from the identity represented to the downstream service, but the claim set must still carry the user’s context. That is the key distinction in on-behalf-of style designs and similar delegation patterns described in RFC 8693: OAuth 2.0 Token Exchange and the surrounding OAuth and OpenID Connect model in RFC 6749: The OAuth 2.0 Authorization Framework and OpenID Connect Core 1.0.
If the exchange strips or rewrites the claims that represent the user, the downstream service is no longer making a decision on the original subject. At that point, authorization can drift toward “who presented the token” instead of “which user initiated the action,” which is exactly where federated integrations become brittle.
What must remain consistent across ADFS, ACS, and the service boundary
The design goal is claim integrity, not token reuse. The service should receive enough information to preserve subject continuity, audience intent, and delegation context across each hop. That means the federation layer, the exchange step, and the final Azure service integration all need a consistent interpretation of subject, issuer, and audience so that the user remains visible even if the credential format changes.
In practice, the most common failure is treating the caller and the user as the same thing. In a federated flow, the caller may be an application or broker, while the user remains the actionable subject that the service should recognize. If the system reduces both into a single opaque bearer token, the service loses the ability to apply user-scoped policy, trace delegated actions, or distinguish user context from service context.
That is why the token exchange boundary must be designed as a policy boundary, not just a transport step. The same principle appears in identity and federation guidance such as OAuth 2.0 and OpenID Connect Guide for Identity Teams, which is useful when teams need to reason about claims, scopes, grants, and exchanged tokens as separate design choices.
How to preserve identity without weakening the trust model
Security teams should preserve identity by explicitly mapping the end user to the caller identity, then carrying the minimum claim set needed for the downstream authorization decision. The service should receive a token that still expresses who initiated the action, what the caller is allowed to do, and what resource the token was intended for. That is the practical difference between a secure delegated flow and a generic service credential handoff.
Where Azure integrations depend on federation or token exchange, the safest pattern is to keep claims stable enough for authorization while still constraining them to the target service. This is why audience restriction, sender-constrained tokens, and token-bound access patterns matter: they reduce replay and token substitution risk without erasing user context. Teams that want a deeper implementation reference for identity-preserving authentication patterns can use NHI Authentication Guide as a practical companion on federation, delegation, and token-based authentication models.
For Azure-specific integration architectures, the important discipline is to document which identity is authoritative at each hop, which claims must survive exchange, and which service makes the final decision. If the architecture cannot answer those three questions clearly, identity continuity is already at risk.
Risk and Threat Considerations
Federated token exchange creates a subtle failure mode: the system may still work while silently losing the end user’s identity. That exposes organisations to overbroad access, weak auditability, and delegation confusion, especially when downstream services trust the exchanged token without validating whether the user context survived intact.
Failure mechanism: A token exchange can replace a user-scoped identity with a caller-scoped one, or strip claims needed to prove who initiated the action. Once that happens, authorization, logging, and policy enforcement can all key off the wrong subject.
Impact: Downstream services may grant access that is too broad, fail to enforce user-specific controls, or produce audit trails that cannot distinguish delegated action from direct service action. In regulated or high-assurance environments, that weakens accountability and can mask abuse.
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 surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Token exchange and delegated access depend on preserving and validating the right caller identity. |
| Recommendation — Validate exchanged tokens so the downstream service still authenticates the intended subject. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Federated service integrations rely on authenticating non-human callers and preserving trust across hops. |
| AC-6 — Least Privilege | Claim loss or identity collapse can widen access beyond the original user's intended authority. | |
| AU-2 — Event Logging | Claim continuity across federated hops is needed for auditable user attribution. | |
| Recommendation — Authenticate service-to-service exchanges with controls that preserve subject continuity. Limit delegated access so exchanged tokens carry only the minimum required authority. Log the original subject, broker, and resource audience for each token exchange. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Federated access design must preserve controlled authorization decisions across trust boundaries. |
| Recommendation — Define access rules that keep user context intact through federation and token exchange. | ||
Practitioner Guidance
What to verify: Confirm that the exchanged token still carries the claims the service actually uses for authorization, not just a valid signature. Check subject, issuer, audience, and any delegation markers end to end before trusting the flow.
Decision rule: If the downstream service needs to make a decision about the end user, do not allow the exchange step to collapse the user into a generic service caller. If the service only needs system-level access, keep that path separate so user context is not artificially implied.
What good looks like: The service can answer three questions from the token and surrounding context: who initiated the action, which actor presented the token, and what resource the token was meant for. If any of those answers are ambiguous, the design is too loose for reliable delegation.
Practitioner takeaway: The objective is not simply to make token exchange succeed, it is to preserve a trustworthy chain of identity so the receiving service can still authorize the original user, not just the broker that relayed the request.
Related resources from NHI Mgmt Group
- How do security teams decide whether to use token-based or identity provider based access for GitLab integrations?
- How should security teams implement strong password generation across user accounts and service access points?
- How should security teams evaluate identity providers for federated access across multiple applications?
- How should security teams design user access reviews across different applications and risk levels?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
