Asynchronous Authorization

This process relies on a decoupled authentication flow where the user provides consent on a trusted device, such as their mobile phone, separate from the device where the agent was initially engaged.

Use cases for asynchronous authorization

AI agents often need to perform actions that are long-running, are executed at a later time, or involve sensitive operations. For example:

Transactional approvals: An agent arranging a business trip might find a flight and hotel, but needs the user’s final approval to complete the purchase.
Accessing sensitive data: An agent might need to access a protected user’s health records to answer a query.
Executing high-privilege tasks: A DevOps agent might need permission to deploy a new version of an application to a production environment.

In these scenarios, the agent needs the user to approve an action at a later time. Asynchronous authorization allows the agent to initiate this request and let the user approve it at their convenience, creating a more seamless and secure user experience. This decoupled mechanism is also ideal for human-in-the-loop interactions, such as approving a stock purchase through a chatbot or completing a financial transaction with a banking agent.

Client-Initiated Backchannel Authentication and Rich Authorization Requests

Auth0 implements asynchronous authorization using the Client-Initiated Backchannel Authentication (CIBA) standard, enhanced with Rich Authorization Requests (RAR).

CIBA is an OpenID Foundation specification that defines a decoupled flow where a client application (the AI agent’s backend, for example) can initiate an authentication request without direct interaction from the user on the same device. The user then approves or denies the request on a separate, trusted authentication device (like a mobile phone), typically via a push notification to an authenticator app or via SMS or email.
RAR is an OAuth 2.0 extension that allows client applications to request more complex permissions beyond standard OAuth 2.0 scopes in an authorization request. It allows the agent to send a detailed, structured payload describing the exact transaction. This provides the user with specific, verifiable context such as “Approve payment of $50.00 to ExampleCorp”, instead of a generic prompt, which is critical for establishing user trust and security. Using RAR is optional for a CIBA flow.

The flow generally proceeds as follows:

Initiation

The agent’s backend identifies a need for user approval and sends a CIBA request to the Auth0 /bc-authorize endpoint. This request includes a user identifier and the optional RAR payload in the (authorization_details) parameter.

Acknowledgment

Auth0 immediately acknowledges the request by returning a unique auth_req_id.

Polling

The agent’s backend uses auth_req_id to begin polling the Auth0 /token endpoint to check for completion.

User consent

In parallel, Auth0 sends a notification (e.g., push, SMS, or email) to the user’s authentication device, displaying the rich context from the RAR payload. The user approves or denies the request.

Token issuance

Once the user approves, the next polling request from the agent’s backend to the /token endpoint will succeed. Auth0 returns the required access and ID tokens, allowing the agent to complete the authorized action.

When sending the backchannel authorization request, Auth0 must decide the appropriate notification channel when reaching the user for approval. These are the currently available options (in order of preference):

MFA Push Notification: Challenge MFA Push factor which sends a push notification to the user’s enrolled device. Authentication and authorization happens in the device that received the notification.
Email: Sends an email to a verified address associated to the user. The email contains a link and authentication & authorization happens in the browser.

Enterprise Feature: Email notifications for asynchronous authorization are now available for Enterprise plans.

The selection logic of the channel will be by the order in the list above. However, there are factors that may influence the decision.

The Auth0 client’s notification channel: within the Auth0 application details screen, notification channels can be enabled or disabled for asynchronous authorization requests. These will configure the client’s async_approval_notification_channels array setting. Currently available options are guardian-push and email.
Requested expiry: when the agent’s backend specifies a requested expiry greater than 5 minutes, MFA Push notification becomes a non-eligible option.
MFA configuration at the tenant level: a MFA Push Notification channel must be configured for the tenant for this notification channel to be selected. See more details here about configuring your tenant to use Auth0 Guardian with push notifications. (note: only the Auth0 Guardian push factor is supported at this time.)
User’s enrolled authenticators: if the user is not enrolled to use an MFA push authenticator, the current behavior is to fallback to Email instead of rejecting the request.
User’s email verification status: if the user’s email is not verified, we assume sending emails to an unverified email address is not desired, and the request will be rejected.

You can read more about the notification channel selection in the Configure Client-Initiated Backchannel Authentication documentation.

Get started

To begin using Asynchronous Authorization in your AI agents, refer to the following resources:

Quickstarts