An identity orchestration platform will sit in the path of every sign-in it handles and hold credentials for every service it connects, so a poor choice is both a security risk and a long-term lock-in. Products in this space range from journey and flow engines that sequence authenticators, verification and fraud checks, to federation brokers that hide several identity providers behind one issuer, to policy orchestration tools that translate central policy into the native controls of clouds and SaaS. Many IdP and CIAM platforms also offer orchestration features of their own. This vendor-neutral guide helps IAM architects and buyers define requirements, compare platforms on criteria that matter, and run a proof of concept that tests failure as well as success.
Key takeaways
- Buy for your problem, not the category label. IdP migration, customer journey agility, policy consistency across clouds and agent access need different capabilities.
- Standards are the exit plan. Require OIDC, SAML, SCIM, OAuth token exchange, Shared Signals with CAEP and an AuthZEN-style decision interface, plus export of flows and policies.
- Judge the platform as a tier 0 system. Key custody, admin controls, change control and tenant isolation matter as much as the flow designer.
- Test availability and failure modes. Ask what happens when a connector, risk engine or upstream IdP is slow or down, and prove it in the proof of concept.
- Check readiness for AI agents. Delegated, audience-bound tokens and per-call authorisation for MCP and agent traffic should be on the roadmap or in the product.
Define requirements
- Drivers: mergers and IdP consolidation, customer experience changes without app releases, consistent access policy across clouds and data platforms, continuous access evaluation, or agent and MCP access. Rank them; they lead to different shortlists.
- Audiences: workforce, contractors, consumers, business customers, patients and carers, partners, workloads and AI agents. See the Customer IAM (CIAM) Guide for customer-facing needs.
- Current estate: every IdP, directory, MFA, identity verification, fraud and authorisation service the platform must call, and the protocols each application uses today. Foundations are in IAM and IGA Basics.
- Assurance targets: required authentication and federation assurance per application, for example NIST SP 800-63-4 AAL and FAL levels, and whether the platform must pass upstream assurance through accurately. NIST SP 800-63C-4 states that the effective FAL of a proxied connection is the lowest along the path.
- Scale and availability: peak sign-ins per second, regional deployment, recovery objectives and whether the platform may sit in a single point of failure position.
- Operating model: who builds and changes flows (IAM engineers, developers, product teams), and whether you need flows as code with CI/CD or a visual designer, or both.
- Build or extend: whether your main IdP's own extensibility (event hooks that call your APIs at token issuance or registration) already covers the need.
Capability areas
| Area | What to look for |
|---|---|
| Journey orchestration | Registration, sign-in, step-up, recovery and consent flows; home realm discovery; conditional branching on risk and context; versioned flows with staged rollout and rollback |
| Federation brokering | OIDC and SAML upstream and downstream, stable issuer for migrations, accurate acr and amr propagation, per-application minimum assurance. See the Federation and Trust Relationships Guide |
| Connectors | Directories, HR systems, MFA, identity verification, fraud and bot tools; connector credentials held in a vault with rotation and least privilege |
| Attribute and claims | Fetching and normalising attributes from several sources at token issuance; SCIM provisioning rather than relying only on just-in-time creation. See the SCIM Provisioning Guide |
| Authorisation | Externalised decisions through a standard interface such as the OpenID AuthZEN Authorization API (/access/v1/evaluation), or design-time translation of policy into native controls. See the Externalised Authorisation Buyer's Guide |
| Continuous access | OpenID Shared Signals Framework transmitter and receiver, CAEP events such as session-revoked, credential-change and device-compliance-change, with measurable propagation time. See the Shared Signals Framework Guide |
| Agent and MCP access | OAuth 2.0 Token Exchange (RFC 8693) with act for delegation, RFC 8707 resource indicators, audience validation, no token passthrough, policy-gated client registration. See the AI Agent Identity Security Buyer's Guide |
| Control plane security | Phishing-resistant admin MFA, granular admin roles, approval for flow and trust changes, HSM or KMS key custody, full admin audit log |
| Observability | Per-execution logs with flow version, dependencies called, latency and decision reasons; streaming to SIEM; test and simulation tooling |
Evaluation criteria
| Criterion | Strong answer | Weak answer |
|---|---|---|
| Standards conformance | Certified or tested OIDC, SAML, SCIM; SSF and CAEP; RFC 8693; AuthZEN or documented decision API | Proprietary SDKs required in every application |
| Portability | Flows and policies exportable as readable files; API for every admin action | Logic locked in a visual canvas with no export |
| OAuth security posture | Follows RFC 9700: exact redirect matching, PKCE S256, no implicit or password grant, issuer identification, sender-constrained tokens (mTLS or DPoP) | Legacy grants enabled by default |
| Resilience | Documented per-dependency timeouts, fail-open or fail-closed settings, regional failover, published availability history | "It does not go down" |
| Change control | Environments, versioning, peer approval, rollback in one step, CI/CD support | Edits apply straight to production |
| Key and secret custody | Signing keys in HSM or KMS, customer-managed keys option, connector secrets never returned by APIs | Secrets readable through admin or API calls |
| Assurance honesty | Upstream authentication context passed through; downstream minimums enforced | Broker always asserts strong authentication |
| Total cost | Predictable pricing by users, applications or executions, with test environments included | Per-connector or per-execution fees that punish adding signals |
Questions to ask vendors
- Show us an IdP migration: applications on a stable issuer, users moved behind it in waves, and rollback of one wave.
- When an upstream IdP authenticates a user with a password only, what do downstream applications see in
acrandamr, and can we block that for specific applications? - What happens to a sign-in when the fraud connector times out? Where is that behaviour configured and logged?
- Where are assertion signing keys and connector secrets stored, who at your company can access them, and can any API return a stored secret?
- How are flow and trust changes approved, versioned and rolled back, and can we manage them from our own CI/CD pipeline?
- Which Shared Signals events do you transmit and receive, and how long does a session-revoked event take to end downstream sessions?
- How does an AI agent get a delegated token for a user, how is the agent identified in the token and logs, and how do you prevent token passthrough to downstream APIs?
- Can we export every flow and policy in a readable format if we leave?
Red flags
- Admin APIs that return stored client secrets or connector credentials. The OneLogin API flaw showed how an API listing applications exposed OIDC client secrets to any API key holder.
- No separation between design and production environments, or no one-step rollback.
- The broker always reports strong authentication regardless of what the upstream IdP did.
- Impersonation as the only model for agent or service access.
- Vague answers on signing key custody, tenant isolation or support staff access.
- Orchestration logic that can only be expressed in a proprietary format with no export.
Proof of concept
- Integrate two upstream IdPs and three applications using OIDC, SAML and one legacy pattern, behind a single issuer.
- Build sign-in with risk-based step-up to a phishing-resistant authenticator, plus account recovery, and check that recovery cannot skip the strong checks.
- Inject failures: slow and unavailable fraud connector, unavailable upstream IdP, expired connector secret. Confirm each behaves as configured and is logged.
- Send a CAEP session-revoked event and time the end of downstream sessions.
- Run an agent scenario with token exchange: confirm the token carries the user and the agent, is audience-bound, and is rejected by a different resource.
- Make a flow change through your pipeline with peer approval, deploy, then roll it back.
- Export flows, policies and logs, and review them with your audit team.
- Load test at expected peak sign-in rate.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support across identity orchestration, IAM, CIAM, IGA, PAM and NHI. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Identity Orchestration Guide · CIAM Buyer's Guide · IAM and IdP Buyer's Guide · Identity Provider and SSO Security Guide