Completing backchannel authentication transactions
PingOne Advanced Identity Cloud PingAM Android iOS
Advanced Identity Cloud and PingAM support a server-initiated, backchannel authentication pattern. A third-party federation service starts an authentication transaction on behalf of a user, and can provide some of the credentials. The user then completes that transaction by following an authentication journey in your app.
|
This is not OIDC Client-Initiated Backchannel Authentication (CIBA). This page covers a proprietary backchannel authentication mechanism in Advanced Identity Cloud and PingAM, a transactional authentication pattern that is unrelated to the OIDC CIBA grant type. |
Why use backchannel authentication?
Some scenarios require a party other than the user’s own device to initiate authentication. For example:
-
A service that already recognizes the user, such as a banking backend evaluating a large funds transfer, determines that the requested operation is too risky for the user’s current authentication level, and needs to step them up to a stronger one before proceeding.
-
A partner or federated service already holds context about the user and wants to trigger an authentication journey without asking them to re-enter identifying details.
-
A backend system needs the user to confirm or approve an action, and wants to route that confirmation through an authentication journey rather than build a custom approval flow.
In each case, the transaction is created on the server before your app is involved, and your app’s job is to complete the resulting journey.
How the transaction works
A backchannel authentication transaction begins and ends on the server; your app only gets involved in the middle to handle the authentication journey.
The full lifecycle looks like this:
-
A federation service calls Advanced Identity Cloud’s or PingAM’s backchannel initialization endpoint, providing details such as the journey to run and the subject (user) it’s for.
-
The server creates a transaction and returns a transaction ID together with a backchannel transaction URI that encodes that transaction ID.
-
The federation service delivers the backchannel transaction URI to your app.
How your app receives that URI is an implementation detail for you to decide, such as a deep link, a push notification payload, or a custom transport your backend already uses.
-
Your app passes the backchannel transaction URI to the SDK, which uses it to contact the server and start the journey associated with that transaction.
-
The server starts the authentication journey.
-
Your user completes the journey as normal, interacting with your app.
-
On successful completion, the journey reports success to the server.
-
The server returns a session to your app. The federation service can separately check the transaction’s status and outcome.
The Orchestration SDKs only handle steps 4 through 8: starting the journey from the backchannel transaction URI, and letting your user complete it. Initiating the transaction, and checking its outcome afterwards, happens entirely on the server side, outside of the Orchestration SDKs.
To learn about configuring and initializing backchannel authentication, refer to the following pages:
- PingOne Advanced Identity Cloud
- PingAM