The identity industry is a terminology quagmire. Ideas and concepts are encapsulated in words and phrases that often seem interchangeable or confusing. Take the words authentication and authorisation. These two mechanisms are vital to an identity system but are often misunderstood. Where authentication checks a user is who they say they are, authorisation verifies the person’s rights to resources once authenticated. The two work together but are quite different.
A term new to the identity scene is identity orchestration. However, this new technology has two main variants – identity orchestration for consumer systems and enterprise identity orchestration. Understanding the differences between the two types of identity orchestration is important so you can make the right choice when designing your identity-reliant government service.
Why do we need identity orchestration?
Before discussing the various aspects of the two flavours of orchestration, it’s worth reviewing the reasons orchestration has emerged and why it’s an enabling component in an identity system.

Identity-reliant services, like online government access, have been a “work in progress”, with various solutions entering the landscape, then disappearing, only to be reinvented. One of the ongoing challenges of identity services, whether for citizens or internal users, is the streamlining and coordination of user journeys. Before orchestration, user journeys were often hard-coded, complex to modify, and inflexible. Orchestration changed this situation by allowing system designers and administrators to “orchestrate” these journeys.
Orchestration platforms provide connectivity to identity-associated apps and services. This means that the service that needs identity to operate can connect to the orchestration platform, which then connects to the authentication, authorisation, or verification service on its behalf.
Orchestration dramatically simplifies the requirements of an identity-associated service. However, there are different types of identity orchestration, each providing various functions. When choosing ways to make your identity-associated service more secure and easier to use and manage, you must choose the right orchestration option.
One way to differentiate is to think of orchestration for internal use cases centring on authentication and authorisation and for consumers and citizens being more about verification and onboarding. However, both types of orchestration have some overlap; both types of identity orchestration are there to make life easier and more secure for the service and the people using it.
Enterprise identity orchestration for internal use cases
Internal users encompass employees, consultants, freelancers, and the broader supply chain. Orchestration benefits identity and access management by providing an abstraction layer on top of IAM to manage access and authorisation across multiple IDPs. The purpose of enterprise orchestration (sometimes called journey-time orchestration) is to connect components of an identity ecosystem involved in user registration, login, and MFA. Some enterprise orchestration solutions connect to CRM (customer relationship management) systems and external user stores.
Enterprise identity orchestration platforms, like SailPoint, automate identity security workflows, reducing the overhead of identity governance.
Identity orchestration for consumer and citizen use cases
Services that offer resources for citizens and consumers have different needs from enterprise identity orchestration. Consumers and citizens are external users and, therefore, completely unknown to the system. In the case of citizens and consumers, identity orchestration places a focus on verification.
Verification of personally identifying data is often required to control resource access. This verification includes KYC/CDD (Know Your Customer/Customer Due Diligence) and anti-fraud checks. The verification checks can happen at any stage of the interaction with a platform and are often step-up verification, i.e., multiple sources of data and identity checks are orchestrated. Identity checks for citizens may also have complex user journeys with data collection and verification during onboarding and when transactions occur post-account creation.
Verification orchestration, or step-up verification, can also be used to verify and validate a consumer or citizen without creating an account.
If you liked this content…
What do both types of identity verification have in common?
Both types of identity orchestration solutions have certain elements in common, including the following:
Modifiable user journeys: The prime function of both identity orchestration variants is to modify user journeys. Some solutions present user journey flows in an interface and allow drag-and-drop actions (nodes) to move journey events around. Typically, these flows are template-based and have limitations.
Connectivity: Orchestration automates connectivity to apps, systems, and services. For example, orchestration that deals with internal users typically connects to SaaS apps and provides Single Sign-On (SSO) across those apps. Consumer and citizen identity orchestration connects to verification services and sources, such as banks, and provides verified data to online services, such as government portals.
Other features to look out for in an identity orchestration solution include:
Data transformation and normalisation: Identity orchestration solutions, particularly those that provide connection to verification services, must be able to transform and normalise data. This is vital to allowing the service requesting the data to consume it easily.
Protocol handling: Online services must handle identity and authentication protocols, some of which are complex to implement. For example, FAPI is an API security profile for financial-grade transactions that is based on OAuth 2.0. Some orchestration solutions will translate protocols for the online requesting service, handling all the protocol handling heavy work.
Dynamic vs. static identity orchestration
One of the core differentiators of identity orchestration platforms is that some solutions rely on a GUI to set up user journey pathways. The positive aspect of GUI-based orchestration solutions is that they are easy to use and allow administrators to use visual tools to configure the system. However, the Ying to this Yang is that the orchestration capability of static systems is confined to a template: an administrator or system designer must decide upfront what user journey pathways are allowed.
The GUI approach to user journey orchestration leads to static decisions that offer easy-to-use tools, but this ease of use comes at the price of flexibility and extensibility.
Conversely, some verification orchestration solutions, like Avoco ODE, use a dynamic rules-based system based on scripting and are not dependent on a GUI. Using scripting provides a more flexible way to modify user journeys. These dynamic rules-based identity orchestration solutions modify user journeys in real time. For example, a rule can be used to initiate alternative verification methods, like vouching, if a person fails to verify after X attempts. A GUI can still be used with these identity orchestration solutions but as an overlay and not the control system.
Government organisations can benefit from using identity orchestration as these technologies automate and extend the capability of an identity-reliant service. Whether your needs are internal or to service a mass-demographic citizen user base, there is an orchestration platform for you and the people using your service.






