MENU
Which OpenID Connect grant flow is best to use when the relying party knows the user's identifier and wishes to gain consent for an operation from the user by means of a separate authentication device?
The scenario described---where a client (Relying Party) already knows who the user is and needs them to authorize an action on a different device---is the primary use case for the Backchannel Request Grant, also known as Client-Initiated Backchannel Authentication (CIBA).
According to the PingAM 8.0.2 documentation on 'OpenID Connect Grant Flows' and 'CIBA':
Unlike traditional OIDC flows (Implicit, Authorization Code, Hybrid) that require a browser redirect (front-channel) to the OpenID Provider, CIBA is a back-channel flow. It is designed for 'decoupled' authentication.
The Trigger: The RP sends a request directly to PingAM's backchannel authentication endpoint, providing a user identifier (like a username or email).
The Consent: PingAM then reaches out to the user's Authentication Device (usually a smartphone with the ForgeRock Authenticator app) via a Push notification.
The Approval: The user approves the request on their phone.
The Tokens: The RP, which has been polling PingAM or waiting for a callback, receives the ID Token and Access Token.
Common real-world examples include a bank teller initiating a login on their terminal which the customer approves on their mobile banking app, or a call center agent verifying a caller's identity via a push notification. Option D is the only flow that supports this decoupled, separate-device architecture. Options A, B, and C are all 'Front-channel' flows that require the user's interaction to happen in the same browser session that initiated the request.