Identity Orchestration Guide: Unifying Fragmented Identity Systems

Most organisations run several identity providers, directories, MFA tools and policy engines at once, and every application ends up wired to a different subset of them. Identity orchestration is the practice of putting a coordinating layer between applications and those identity services, so that sign-in journeys, risk checks, attribute lookups, authorisation decisions and session revocation are defined once and applied everywhere. Done well, it lets you migrate an identity provider, add passkeys or bring AI agents under policy without rewriting each application. Done badly, it creates a single, highly privileged component that holds every client secret and signing key you own. This guide is for IAM architects and engineers designing or reviewing an orchestration layer for workforce, customer, patient or agent access.

Key takeaways

• Orchestration is coordination, not another IdP. It routes, sequences and translates between identity services you already run, through standard protocols, and should not become a new store of truth for identities.
• Separate design-time and runtime orchestration. Policy orchestration translates and distributes policy to native systems ahead of time; runtime orchestration sits in the sign-in and request path and must be engineered for availability.
• The layer is a tier 0 asset. It acts as a relying party upstream and an identity provider downstream, so it inherits the obligations and the attack surface of both. NIST SP 800-63C-4 says the effective assurance of a proxied connection is the lowest along the path.
• Standards keep it replaceable. OIDC, SAML, SCIM, OAuth token exchange (RFC 8693), the OpenID Shared Signals Framework with CAEP, and the AuthZEN Authorization API stop the orchestration layer becoming the next lock-in.
• Agents raise the stakes. MCP servers and AI agents need audience-bound, delegated tokens; an orchestration layer that passes tokens through or impersonates users removes the accountability you need.

What identity orchestration is, and what it is not

Identity orchestration coordinates identity services across a fragmented estate: several workforce IdPs after acquisitions, a legacy access manager on premises, a CIAM platform for customers, separate MFA, identity verification and fraud tools, and a growing number of authorisation engines. Instead of each application integrating with each service, applications integrate once with the orchestration layer, and the layer decides which services to call, in which order, with which data.

• Journey orchestration: the sequence of steps a person or client goes through at registration, sign-in, step-up, recovery or consent, including which IdP to route to (home realm discovery), which authenticator to request and which risk or verification service to consult.
• Attribute and claims orchestration: fetching and normalising attributes from several sources at token issuance, so applications receive one consistent set of claims. See the Identity Data Quality Guide.
• Policy orchestration: defining access policy centrally and translating it into the native policy formats of each cloud, SaaS application or data platform. The open-source Hexa project, for example, describes discovering native policy, translating it to and from its IDQL policy language, and distributing it to targets such as cloud identity providers, AWS, GCP, Snowflake, Databricks and OPA, through administrative processes rather than in the runtime path.
• Signal orchestration: moving security events such as session revocation, credential change or device compliance change between systems so that one decision updates access everywhere. See the Shared Signals Framework Guide.

Orchestration is not a replacement for identity governance. It does not decide who should have which entitlement or run access reviews; that remains the job of IGA. It is also not a reason to skip consolidation: if you can retire a redundant IdP, retiring it is usually cheaper than orchestrating it forever. For the foundations, see IAM and IGA Basics.

Architecture patterns for the orchestration layer

There are four common ways to build the layer. Many organisations combine two of them, for example a federation broker for sign-in plus a policy orchestration tool for downstream permissions.

Where decisions are made and enforced

Keep the policy decision point (PDP) and the policy enforcement point (PEP) distinct. The OpenID AuthZEN Authorization API 1.0, final since January 2026, standardises this interface: the PEP sends a subject, action, resource and optional context to /access/v1/evaluation (or a batch to /access/v1/evaluations) and receives a boolean decision, with a denial returned as HTTP 200 and "decision": false rather than an error. An orchestration layer that speaks AuthZEN can swap PDPs without changing every enforcement point. See the Policy-as-Code for Authorisation Guide and the Authorisation Models Guide.

Runtime orchestration: journeys, risk and continuous access

Runtime orchestration is where most value and most risk live, because it is in the path of every sign-in. Design journeys around assurance outcomes, not screens.

1. Identify the subject and route: home realm discovery by email domain, client or network, then federate to the correct upstream IdP. Carry the upstream authentication context forward instead of discarding it.
2. Collect signals: device posture, network, bot and fraud scores, breached-credential checks. Treat each signal source as a dependency with a timeout and a defined failure behaviour.
3. Decide and step up: require a phishing-resistant authenticator for sensitive actions. NIST SP 800-63C-4 requires the IdP to signal IAL, AAL and FAL for each transaction and says a relying party cannot assume a default when none is claimed, so pass acr and amr values through accurately.
4. Issue tokens: one consistent claims set, audience-restricted to the target application, short-lived, with sender constraint (mTLS per RFC 8705 or DPoP per RFC 9449) where the client supports it, as RFC 9700 recommends.
5. Keep evaluating: subscribe to and publish Shared Signals events so that a change after sign-in takes effect.

Continuous access with Shared Signals and CAEP

The OpenID Shared Signals Framework 1.0 defines Transmitters and Receivers exchanging Security Event Tokens (RFC 8417, header typ: secevent+jwt, subject in a top-level sub_id) by push (RFC 8935) or poll (RFC 8936), discovered at /.well-known/ssf-configuration. Streams can be enabled, paused or disabled, and a verification endpoint lets you test delivery end to end. The orchestration layer is a natural hub for these streams.

Orchestration across audiences: workforce, customer, patient and retail

• Workforce: the common driver is mergers and IdP migration. Put a stable issuer in front of applications, migrate users behind it in waves, and retire the old IdP only when its sign-in logs show no traffic. Keep provisioning on SCIM rather than just-in-time creation from assertions, so that leavers are removed. See the SCIM Provisioning Guide.
• Customer and consumer: orchestration ties the CIAM platform to identity verification, fraud and consent tools, and lets you add passkeys or progressive profiling without app releases. Measure conversion and fraud together. See the Customer IAM (CIAM) Guide.
• Retail: peak trading events, loyalty accounts and guest checkout make availability and bot defence the dominant requirements; a journey that fails closed on Black Friday is a business incident. See the Retail and E-Commerce Identity Security Guide.
• Patient and healthcare: clinicians, patients, carers and proxies need different assurance and delegation, and clinical workflows cannot tolerate repeated prompts. Proxy and carer access is a delegation problem: model it explicitly rather than sharing credentials. See the Healthcare Identity Security Guide.
• Business customers (B2B): federation with each customer's IdP is orchestration at scale; treat every inbound trust as a supplier relationship with an owner and review date. See the Federation and Trust Relationships Guide.

Agentic and MCP identity orchestration

AI agents add a new kind of client to the orchestration layer: software acting for a person, often through several hops. The Model Context Protocol authorisation specification (June 2025 revision) makes an HTTP-based MCP server an OAuth 2.1 resource server. It must publish OAuth 2.0 Protected Resource Metadata (RFC 9728), clients must send the RFC 8707 resource parameter naming the server's canonical URI, PKCE is mandatory, and the server must validate that tokens were issued for it. Crucially, an MCP server that calls upstream APIs must not pass through the token it received; it needs a separate token for the upstream resource. STDIO-based local servers are outside that specification and take credentials from the environment, which is where orchestration often stops seeing them.

• Delegate, do not impersonate: use OAuth 2.0 Token Exchange (RFC 8693, grant type urn:ietf:params:oauth:grant-type:token-exchange) so the issued token carries the user as sub and the agent as act. Impersonation makes the agent indistinguishable from the user in logs. Use may_act to state which agents may act for whom. See the OAuth Token Exchange and Delegation Guide.
• Narrow every hop: each exchange should reduce scope and audience, never widen it. OWASP's LLM06:2025 Excessive Agency names excessive functionality, permissions and autonomy as root causes, and the orchestration layer is where permissions per hop can be enforced.
• Put a PDP behind tool calls: an AuthZEN-style check per tool invocation, with the agent, the user and the tool as inputs, is easier to audit than scopes alone. See the AI Agent Authorisation Guide.
• Register agents as identities: dynamic client registration (RFC 7591) is recommended by MCP for convenience, but unrestricted registration lets any client obtain a client ID. Gate registration by policy and record an owner. See the MCP Security Guide and the Multi-Agent and A2A Security Guide.

Securing the orchestration layer itself

The layer holds the keys to everything it connects. NIST SP 800-63C-4 states that a proxy acts as a relying party upstream and an IdP downstream, that all requirements of both roles apply, that its assertions must name the proxy as issuer, and that it gains visibility of subscriber activity, which adds privacy and security risk.

• Connector credentials are NHIs: every connector to a directory, HR system, fraud tool or SaaS API is a service identity with a secret. Store them in a vault, scope them to the minimum, rotate them and assign owners. See the NHI Authentication Guide.
• Validate callers of your hooks: Microsoft's documentation for custom authentication extensions tells you to check the bearer token's azp or appid (the Entra service ID 99045fe1-7639-4a75-9d4a-577b6ca3810f), aud and iss. A hook endpoint that accepts any caller can inject claims into tokens.
• Follow the OAuth BCP: RFC 9700 calls for exact redirect URI matching, no implicit or password grants, PKCE with S256, and issuer identification (RFC 9207) for clients that talk to several authorisation servers, which an orchestration layer always does.
• Design for failure: define per dependency whether the journey fails open (for a low-risk enrichment) or closed (for authentication), with timeouts, cached decisions with short validity and a tested break-glass path.

How to implement: a phased rollout

1. Inventory: list every IdP, directory, MFA, verification, fraud and authorisation service, each application's integration and protocol, and every trust, secret and signing key. Mark owners.
2. Decide scope and pattern: pick journeys and policy domains to orchestrate first; record which services you will retire rather than orchestrate.
3. Build the control plane first: admin MFA, flows as code in version control, separate non-production tenant, secrets in a vault, logging to your SIEM before any production traffic.
4. Pilot in shadow or audit mode: run policy decisions in log-only mode and compare with the current outcome; for journeys, route a pilot ring of internal users or one low-risk application.
5. Migrate in waves: move applications behind the stable issuer group by group, with a per-wave rollback that switches the application back to its previous IdP configuration. Keep the old configuration intact until the wave is signed off.
6. Add signals and agents: connect Shared Signals streams, then bring agent and MCP access under token exchange and per-call authorisation.
7. Retire: decommission redundant IdPs and their trusts, revoke their secrets and remove their signing certificates from relying parties.

Decision guidance

• Hooks in your existing IdP versus a separate orchestration layer: if one IdP serves almost all applications, its extensibility hooks are usually enough. A separate layer pays off when you have several IdPs that will coexist for years, or when you need IdP portability.
• Runtime versus design-time policy orchestration: for cloud and data platforms with rich native controls, translating policy into native controls avoids a runtime dependency. For custom applications, a runtime PDP gives finer, context-aware decisions.
• Small organisations: consolidate first; one IdP with a handful of well-reviewed hooks beats an orchestration platform nobody has time to maintain.
• Large or acquisitive organisations: invest in a stable issuer, flows as code and SSF, because IdP change is a recurring event, not a one-off.

Detection and measurement

• Log: every flow execution with flow version, upstream IdP, authenticators used, signal sources and their latency, decisions and reasons; every admin change to flows, connectors, trusts and keys; every token exchange with subject and actor.
• Alert on: new upstream IdPs or signing certificates, flow deployments outside change windows, hook endpoints returning errors, sudden drops in step-up rates, and agent tokens used outside their audience.

Framework mapping

Common failure patterns

• Treating the orchestration layer as plumbing: it ends up administered by a small team with standing admin rights and no alerting, despite holding every application's trust. The SolarWinds compromise showed what a stolen token-signing certificate does: forged SAML tokens let attackers sign in as any user to federated services without MFA.
• Exposing aggregated secrets: a layer that stores client secrets for every connected application concentrates risk in its admin API. The OneLogin API flaw (CVE-2025-59363) returned OIDC client secrets for every application in a tenant to anyone holding a valid API key.
• Weakest-link assurance: a broker issues assertions that look strong to downstream apps while an upstream partner IdP used passwords only. Pass upstream acr and amr honestly and enforce minimums per application.
• Token passthrough for agents: forwarding a user's token through an agent or MCP server to downstream APIs breaks audience boundaries and creates confused deputies.
• Untested branches: recovery and fallback paths in visual flows are rarely tested and often skip the strong checks the main path enforces.
• No exit plan: proprietary flow logic with no export or standards interfaces turns the orchestration layer into the next system you cannot migrate away from.

Practitioner checklist

• Inventory every IdP, trust, signing key, connector and client secret the layer touches, each with an owner.
• Classify the orchestration layer and its admin plane as tier 0, with phishing-resistant MFA and just-in-time admin.
• Keep flows and policies as code with review, versioning and tested rollback.
• Store signing keys in HSM or managed KMS and connector secrets in a vault, with rotation runbooks.
• Pass upstream assurance (acr, amr, IAL, AAL, FAL) to applications and enforce minimums per application.
• Apply RFC 9700: exact redirect matching, PKCE S256, issuer identification, audience restriction, sender-constrained tokens where possible.
• Connect Shared Signals streams and measure revocation latency end to end.
• Use token exchange with act for agents; forbid token passthrough at MCP servers and gateways.
• Define fail-open or fail-closed behaviour per dependency and test break-glass access.
• Record which services will be retired and track their decommissioning.

Standards and references

• NIST: SP 800-63C-4 Federation and Assertions
• OpenID Foundation: Shared Signals Framework 1.0
• OpenID Foundation: Continuous Access Evaluation Profile 1.0
• OpenID Foundation: AuthZEN Authorization API 1.0
• IETF: RFC 8693 OAuth 2.0 Token Exchange
• IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
• Model Context Protocol: Authorization specification
• Hexa: Policy Orchestration and IDQL

Related NHI Mgmt Group resources: Identity Orchestration Buyer's Guide · CIAM Buyer's Guide · Identity Provider and SSO Security Guide · Zero Trust Identity Guide