Skip to main content
To use Client-Initiated Backchannel Authentication (CIBA) features, you must have an Enterprise Plan or an appropriate add-on. Refer to Auth0 Pricing for details.
The Client-Initiated Backchannel Authentication (CIBA) Flow is an Foundation standard that enables decoupled authentication and authorization using secure backchannel requests. The CIBA flow is designed for use cases where the device initiating a request (the consumption device) is different from the device a user uses to authenticate (the authentication device). In a CIBA flow, there are two actors:
  • Initiating user: The entity that initiates authentication or authorization on the consumption device. This could be a backend application, a human user, such as a customer service agent on a customer service application, or an AI agent performing a task on the end user’s behalf.
  • Authorizing user: The end user who receives the authentication or authorization request on the authentication device and provides consent.
By decoupling authentication and authorization from the consumption device, the client application can directly call the OpenID Provider using a backchannel request. This provides enhanced security, as you can use more secure methods for client authentication like mTLS and Private Key JWT with the CIBA flow.

​
Use cases

Common use cases for CIBA flow include:
  • An AI agent uses human-in-the-loop approvals to request the user’s permission to complete an action requested by the user.
  • 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, for example, 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 payment or change in personal details following a push notification on a personal mobile phone.

​
Notification channels

Auth0 supports the following notification channels with CIBA:
  • Auth0 Guardian mobile push notifications: Available for all Enterprise plans. The user receives a push notification to their enrolled mobile device to authenticate or confirm transaction details. Authentication and authorization happen on the authentication device that receives the push notification. You can enable mobile push notifications with CIBA through:
    • The Auth0 Guardian app
    • A Custom app integrated with the Auth0 Guardian SDK
  • Email notifications: Available as an add-on for paid plans. The user receives an email to their verified email address. The email contains a link, and authentication and authorization happens via the browser.
By default, Auth0 uses and recommends Guardian push notifications for CIBA flows. Guardian push notifications are more secure than other channels such as email, which can be vulnerable to phishing attacks. You have to explicitly enable email notifications for CIBA flows.

​
How it works

The following diagram describes the end-to-end CIBA flow:
  1. The client application or consumption device requests user authentication or authorization.
  2. The client application’s backend submits a POST request to the /bc-authorize endpoint.
  3. Auth0 receives the POST request and sends a notification to the authentication device.
  4. The authentication device retrieves the authorization details from Auth0 and presents them to the end user.
  5. The end user reviews the request, including any contextual authorization details regarding the request.
  6. The end user provides their response on the authentication device, which submits the user response to Auth0.
  7. The client application’s backend polls the /token endpoint and receives the appropriate tokens upon completing the CIBA flow.
Because the CIBA flow is used for one-time asynchronous user authentication and authorization, CIBA does not create or store a grant containing the user’s consent for an application to access an API’s resources. If the user later authenticates using a different authentication flow, and that flow requests the same scopes the user previously consented to using CIBA, Auth0 will not have a record of that consent. Therefore, it will prompt the user to consent again.

​
Get started

Read…To Learn…
Configure Client-Initiated Backchannel AuthenticationHow to configure the CIBA grant type and notification channel for your application.
Mobile push notifications with CIBAHow to authenticate users using the CIBA flow with mobile push notifications.
Email notifications with CIBAHow to authenticate users using the CIBA flow with email notifications.
User Authorization with CIBAHow to authorize users using the CIBA with Rich Authorization Requests (RAR) flow.