Overview

To provide users a simple and secure way to unify identity workflows across API and OIDC applications, IDW users can now transition from using our hosted gateway towards your own API / self-hosted application. This model provides flexibility without sacrificing security — enabling teams to mix and match integration patterns while maintaining a consistent transaction trail.

Mix and match OIDC and API-based integrations.
(Coming soon!) This can configured via. your service's policy manager by obligation type.
User remains authenticated under the same credentials and ASI.

Normally, an AXN Gateway transaction would follow this chain of events:

call /authorize. An ASI (transaction ID) is created by your workflow's first API key.
As the user continues through your workflow... your policy will obligate the user through your workflow's second, third, and fourth API keys... etc.
After the user finishes the verification process... the user is redirected to your OIDC redirect URL with an approve or deny policy decision.

❗️
The user session ends and there's no way for your user session to continue via. the AXN Verify API.

... but with Mixed Integrations, users can:

call /authorize.
Obligate [through the workflow's API keys...]
When an Obligation (Type=API) is reached, we will redirect the user to the callback URL specified in the authorize request but without a final policy decision of either approve / deny.

✅
This way, user are redirected to your callback URL after the gateway flow is complete, but your application can still make requests to our API and reference the same transaction ID from gateway for further identity proofing.

Support of multiple obligation types on a single API key

Because Mixed Integration are rule based ... you can set up rules with different obligation types that won't disrupt the default user experience of other use cases.

→ To get started, please ask your Solutions Architect to assist you in enabling mixed integrations.