> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.com/ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Asynchronous Authorization
> Asynchronous Authorization provides a secure "human-in-the-loop" mechanism, allowing agents to work autonomously in the background and seek user consent for sensitive or critical actions only when necessary.
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**](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html) 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**](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-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:
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.
Auth0 immediately acknowledges the request by returning a unique
`auth_req_id`.
The agent's backend uses `auth_req_id` to begin polling the Auth0 `/token`
endpoint to check for completion.
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.
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.
## User consent and notification channel selection
When Auth0 receives a backchannel request, it must decide which notification channel to use when requesting user approval. These are the currently available options (in order of preference):
1. **Auth0 Guardian mobile push notification**: Sends a mobile push notification to the user's enrolled mobile device. Authentication and authorization happen in the device that received the notification.
2. **Email**: Sends an email to the user's verified address. The email contains a link and, when clicked, authentication & authorization happen in 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.
**Email:** Email notifications for asynchronous authorization is a paid add-on feature, and is now available for all Essentials, Professional, and Enterprise plans. Please see our [pricing](https://auth0.com/pricing) page for more details.
The notification channel Auth0 uses may also be influenced by the following factors:
* The **Auth0 client's notification channel**: within the Auth0 application details screen, you can enable or disable notification channels 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 five minutes, MFA Push notification becomes a non-eligible option.
* **MFA configuration at the tenant level**: To enable the MFA push notification channel for a client application, you must configure MFA push notifications for the tenant. To learn more about configuring your tenant to use Auth0 Guardian with push notifications, read [Enroll in push notifications](https://auth0.com/docs/secure/multi-factor-authentication/auth0-guardian#enroll-in-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, Auth0 falls back to email, if configured, instead of rejecting the CIBA request.
* **User's email verification status**: if the user's email is not verified, Auth0 rejects the CIBA request.
You can read more about the notification channel selection in the [Configure Client-Initiated Backchannel Authentication](https://auth0.com/docs/get-started/applications/configure-client-initiated-backchannel-authentication) documentation.
## Get started
To begin using Asynchronous Authorization in your AI agents, refer to the following resources:
### Quickstarts
### Guides
### Sample Apps
}
horizontal
/>
}
horizontal
/>
}
horizontal
/>
}
horizontal
/>
### Learn more