Client-Initiated Backchannel Authentication Flow

The Client-Initiated Backchannel Authentication (CIBA) Flow is an OpenID Foundation standard for a decoupled authentication flow. It enables solution developers to build authentication flows where the user logging in does not do so directly on the device that receives the ID or access tokens, or the consumption device, but instead on a separate authentication device.

Use the CIBA Flow for the following use cases:

• A user has telephoned a call center, and the agent handling the call would like to access the caller’s personal information on their computer. The caller can consent to this by approving a push notification on their phone. 

• A user would like to access a device with limited input capabilities, such as a bicycle you might rent in a city or a kiosk in a retail setting. 

• A user initiates a sensitive transaction on a relatively insecure device and would like to authorize the transaction on a more secure device. For example, they might authorize a sensitive transaction following a push notification on a personal mobile phone.

The CIBA Flow does not rely on a client application redirecting the user via the browser to perform the login/authentication process. Instead, the client application directly calls the OpenID Provider via a backchannel request to initiate the authentication flow.

The CIBA Flow does not create or update a grant. As a result, if the client application requests a given scope via the CIBA Flow, it won’t be stored as a grant if the user consents. This means that if configured, a different authentication flow (grant type) requesting the same scope(s) must prompt the user again for OAuth consent. 

Because the CIBA Flow does not have sessions i.e. browser cookies, the user does not have to be authenticated before a CIBA challenge. If they were already authenticated before a CIBA challenge, their existing session is not affected.

The following diagram describes the CIBA Flow:

1. The client application or consumption device requests user authentication.

2. The client application’s backend submits a POST request to the /bc-authorize endpoint.

3. Auth0 receives the POST request and sends a push notification to the authentication device.

4. The authentication device retrieves the consent details from Auth0 and presents them to the end user.

5. The end user provides their response on the authentication device which submits the user response to Auth0.

6. The client application’s backend polls the /token endpoint and receives the appropriate tokens upon completing the CIBA flow.