> ## Documentation Index
> Fetch the complete documentation index at: https://docs-staging-quickstart-revamp.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Learn how to use Rich Authorization Requests with the Client-Initiated Backchannel Flow.

# User Authorization with CIBA

[Client-Initiated Backchannel Authentication (CIBA)](/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow) is an <Tooltip tip="OAuth 2.0: Authorization framework that defines authorization protocols and workflows." cta="View Glossary" href="/docs/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> specification that allows a client application to initiate an authentication and/or <Tooltip tip="OAuth 2.0: Authorization framework that defines authorization protocols and workflows." cta="View Glossary" href="/docs/glossary?term=authorization+flow">authorization flow</Tooltip> without requiring direct user interaction on the initiating application. [Rich Authorization Requests (RAR)](/docs/get-started/apis/configure-rich-authorization-requests) is an OAuth 2.0 extension that allows client applications to request for more complex permissions beyond standard OAuth 2.0 scopes in an authorization request.

You can use CIBA with RAR to pass <Tooltip tip="Fine-grained Authorization (FGA): Auth0 product allowing individual users access to specific objects or resources." cta="View Glossary" href="/docs/glossary?term=fine-grained+authorization">fine-grained authorization</Tooltip> data to the <Tooltip tip="Fine-grained Authorization (FGA): Auth0 product allowing individual users access to specific objects or resources." cta="View Glossary" href="/docs/glossary?term=authorization+server">authorization server</Tooltip> in a backchannel request. The `authorization_details` parameter contains details about the request that you can customize in a consent prompt to show the user.

## Common use cases

Use RAR with the CIBA flow for use cases that require more fine-grained control over resource access. Common use cases include:

1. A payments app prompts the user to confirm a money transfer. The `authorization_details` can be customized to show the transaction details.
2. An AI agent prompts the user with details about a rescheduled doctor’s appointment. The `authorization_details` can be customized to show the new time and date.

## How it works

The User Authorization with CIBA flow is similar to the [User Authentication with CIBA flow](/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authentication-with-ciba), where RAR support enables clients to pass the `authorization_details` to the authorization server via the `/bc-authorize` endpoint.

The following sequence diagram explains the end-to-end User Authorization with CIBA flow:

<Frame>
  <img src="https://mintcdn.com/docs-staging-quickstart-revamp/MuTsjoV4fPPSGZz9/images/cdy7uua7fh8z/2i8E4sBBWhQueL4NTt9gz4/a05084a6fd6d39b017572e93c2c9c7b9/Screenshot_2025-06-02_at_1.20.07%C3%A2__PM.png?fit=max&auto=format&n=MuTsjoV4fPPSGZz9&q=85&s=a8c513f944a2420d1b2bdceff5b6353b" alt="" width="1538" height="766" data-path="images/cdy7uua7fh8z/2i8E4sBBWhQueL4NTt9gz4/a05084a6fd6d39b017572e93c2c9c7b9/Screenshot_2025-06-02_at_1.20.07â__PM.png" />
</Frame>

The sequence diagram defines two actors: an authorizing user and an initiating user. The authorizing and initiating user can be two different entities, such as an AI agent performing a task on a user's behalf. In other use cases, they can be the same entity, such as a user authorizing a transaction on a retail kiosk or another connected device.

* [Prerequisites](#prerequisites)
* [Step 1: Client application initiates a CIBA request](#step-1-client-application-initiates-a-ciba-request)
* [Step 2: Auth0 tenant acknowledges the CIBA request](#step-2-auth0-tenant-acknowledges-the-ciba-request)
* [Step 3: Client application polls for a response](#step-3-client-application-polls-for-a-response)
* [Step 4: Mobile application receives the push notification](#step-4-mobile-application-receives-the-push-notification)
* [Step 5: Mobile application retrieves the consent details](#step-5-mobile-application-retrieves-the-consent-details)
* [Step 6: Mobile application presents the consent details to the user](#step-6-mobile-application-presents-the-consent-details-to-the-user)
* [Step 7: Mobile application sends the user response back to Auth0](#step-7-mobile-application-sends-the-user-response-back-to-auth0)
* [Step 8: Auth0 receives user response after the flow completes](#step-8-auth0-receives-user-response-after-the-flow-completes)
* [Step 9: Auth0 returns access token to the client application](#step-9-auth0-returns-access-token-to-client-application)

### Prerequisites

To initiate a CIBA push request using Auth0, you must complete the following prerequisites:

* Integrate your custom mobile application with the [Guardian SDK](/docs/secure/multi-factor-authentication/auth0-guardian#enroll-in-push-notifications). To learn more, read [Configure Client-Initiated Backchannel Authentication](/docs/get-started/applications/configure-client-initiated-backchannel-authentication).
* [Enroll the authorizing user in MFA using push notifications via the Guardian SDK](/docs/secure/multi-factor-authentication/auth0-guardian#enroll-in-push-notifications). To verify in the <Tooltip tip="Auth0 Dashboard: Auth0's main product to configure your services." cta="View Glossary" href="/docs/glossary?term=Auth0+Dashboard">Auth0 Dashboard</Tooltip>, navigate to **User Management > Users** and click on the user:

<Frame>
  <img src="https://mintcdn.com/docs-staging-quickstart-revamp/fNPG21NgQLCA0axA/images/cdy7uua7fh8z/21qtk4F1cOQHMpbXxXYu75/51ba9c5fd1457ffee3f73893acf3c97f/Screenshot_2025-01-13_at_4.13.44_PM.png?fit=max&auto=format&n=fNPG21NgQLCA0axA&q=85&s=33add3bc312b732169eafc1106e0cebc" alt="" width="1616" height="1180" data-path="images/cdy7uua7fh8z/21qtk4F1cOQHMpbXxXYu75/51ba9c5fd1457ffee3f73893acf3c97f/Screenshot_2025-01-13_at_4.13.44_PM.png" />
</Frame>

If you have set <Tooltip tip="Multi-factor authentication (MFA): User authentication process that uses a factor in addition to username and password such as a code via SMS." cta="View Glossary" href="/docs/glossary?term=Multi-factor+Authentication">Multi-factor Authentication</Tooltip> as always required for your tenant, users are prompted to enroll for MFA at their next login. You can also use [Actions](https://auth0.com/blog/using-actions-to-customize-your-mfa-factors/) to prompt for MFA enrollment.

* [Configure Client-Initiated Backchannel Authentication](/docs/get-started/applications/configure-client-initiated-backchannel-authentication) for your tenant and application.
* [Configure Rich Authorization Requests](/docs/get-started/apis/configure-rich-authorization-requests) for your <Tooltip tip="Resource Server: Server hosting protected resources. Resource servers accept and respond to protected resource requests." cta="View Glossary" href="/docs/glossary?term=resource+server">resource server</Tooltip>, which includes registering your `authorization_details` types.

### Step 1: Client application initiates a CIBA request

Use the [User Search APIs](/docs/manage-users/user-search) to find the authorizing user for whom you’d like to initiate a CIBA request and obtain their user ID.

Once you have a user ID for the authorizing user, use the [Authentication API](https://auth0.com/docs/api/authentication/login/start-back-channel-login) to send a CIBA request with the `authorization_details` to the `/bc-authorize` endpoint:

```bash lines
curl --location 'https://$tenant/bc-authorize' \
  --request POST \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'client_id=$client_id' \
  --data-urlencode 'client_secret=$client_secret' \
  --data-urlencode 'login_hint={ "format": "iss_sub", "iss": "https://$tenant/", "sub":"$user_id"}' \
  --data-urlencode 'audience=https://api.example.com' \
  --data-urlencode 'binding_message=Confirm payment of 2500' \
  --data-urlencode 'authorization_details=[{
      "type": "money_transfer", 
      "instructedAmount": {
        "amount": 2500, 
        "currency": "USD"
      }, 
      "sourceAccount": "xxxxxxxxxxx1234", 
      "destinationAccount": "xxxxxxxxxxx9876", 
      "beneficiary": "Hanna Herwitz", 
      "subject": "A Lannister Always Pays His Debts"
    }]'
```

<table class="table">
  <thead>
    <tr>
      <th><strong>Parameters</strong></th>
      <th><strong>Description</strong></th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td><code>tenant</code></td>
      <td>Tenant name. It can also be a custom domain.</td>
    </tr>

    <tr>
      <td><code>client\_id</code></td>
      <td>Client application identifier.</td>
    </tr>

    <tr>
      <td><code>client\_secret</code></td>
      <td>Client authentication method used for user authentication with CIBA, such as Client Secret, Private Key JWT, or mTLS Authentication. If you're using Private Key JWT or mTLS, you don't need to include the client secret.</td>
    </tr>

    <tr>
      <td><code>scope</code></td>
      <td>If the client needs to identify the user (i.e., obtain an <code>id\_token</code>), <code>openid</code> must be included. If the client only needs an access token for authorization, <code>openid</code> is optional, but commonly included.<br /><br />The scope can optionally include <code>offline\_access</code> to request a refresh token. However, for one-time authorization of a transaction with the CIBA Flow, a refresh token is not needed and does not have any meaning in this context.<br /></td>
    </tr>

    <tr>
      <td><code>user\_id</code></td>
      <td>User ID for the authorizing user that is passed within the <code>login\_hint</code> structure. If <code>iss\_sub</code> format is used, then the user ID is passed within the <code>sub</code> claim.<br /><br />The user ID for a federated connection may have a different format.<br /></td>
    </tr>

    <tr>
      <td><code>request\_expiry</code></td>
      <td>The CIBA flow's requested expiry is between 1 and 300 seconds, and it defaults to 300 seconds. Include the <code>request\_expiry</code> parameter to set a custom expiry for the CIBA flow.</td>
    </tr>

    <tr>
      <td><code>binding\_message</code></td>
      <td>Human-readable message used to bind the CIBA flow across the authentication and consumption devices. The binding message is required and up to 64 characters. Use only alphanumeric and <code>+-\_.,:#</code> characters</td>
    </tr>

    <tr>
      <td><code>audience</code></td>
      <td>Unique identifier of the audience for the issued token.</td>
    </tr>

    <tr>
      <td><code>authorization\_details</code></td>
      <td>An optional JSON array of objects that describes the permissions to be authorized. You should register each object’s <code>type</code> value on the resource server using the resource server’s <code>authorization\_details</code> parameter. To learn more, read <a href="/docs/get-started/apis/configure-rich-authorization-requests">Configure Rich Authorization Requests</a>.</td>
    </tr>
  </tbody>
</table>

### Step 2: Auth0 tenant acknowledges the CIBA request

If the Auth0 tenant successfully receives the `POST` request, you should receive a response containing an `auth-req-id` that references the request:

```json lines
{
    "auth_req_id": "eyJh...",
    "expires_in": 300,
    "interval": 5
}
```

The `auth_req_id` value is passed to the `/token` endpoint to poll for the completion of the CIBA flow.

### Step 3: Client application polls for a response

Use the [Authentication API](https://auth0.com/docs/api/authentication/login/start-back-channel-login) to call the `/token` endpoint using the `urn:openid:params:grant-type:ciba` grant type and the `auth_req_id` you received from the `/bc-authorize` endpoint:

<Tabs>
  <Tab title="cURL">
    ```bash lines
    curl --location 'https://$tenant.auth0.com/oauth/token' \
      --header 'Content-Type: application/x-www-form-urlencoded' \
      --data-urlencode 'client_id=$client_id' \
      --data-urlencode 'client_secret=$client_secret' \
      --data-urlencode 'auth_req_id=$auth_req_id' \
      --data-urlencode 'grant_type=urn:openid:params:grant-type:ciba'
    ```
  </Tab>

  <Tab title="C#">
    ```csharp lines
    var token = await authenticationApiClient.GetTokenAsync(
                new ClientInitiatedBackchannelAuthorizationTokenRequest()
                {
                    AuthRequestId = response.AuthRequestId,
                    ClientId = "your-client-id",
                    ClientSecret = "your-client-secret"
                }
            );
    ```
  </Tab>

  <Tab title="Go">
    ```go lines
    token, err := authAPI.OAuth.LoginWithGrant(context.Background(),
    			"urn:openid:params:grant-type:ciba",
    			url.Values{
    				"auth_req_id":   []string{resp.AuthReqID},
    				"client_id":     []string{clientID},
    				"client_secret": []string{clientSecret},
    			},
    			oauth.IDTokenValidationOptions{})
    ```
  </Tab>

  <Tab title="Java">
    ```java lines
    Request<BackChannelTokenResponse> tokenRequest = auth.getBackChannelLoginStatus(authReqId, "grant-type");

    BackChannelTokenResponse tokenResponse = tokenRequest.execute().getBody();
    ```
  </Tab>
</Tabs>

Until the authorizing user approves the transaction, you should receive the following response:

```json lines
{
    "error": "authorization_pending",
    "error_description": "The end-user authorization is pending"
}
```

There is approximately a five-second wait interval for polling. If you poll too frequently, you will receive the following response, where the description varies depending on the backoff interval:

```json lines
{
"error": "slow_down",
"error_description": "You are polling faster than allowed. Try again in 10 seconds."
"interval": 10
}
```

To resolve the error, wait until the next interval (in seconds) to poll the `/token` endpoint.

### Step 4: Mobile application receives the push notification

Auth0 sends a push notification to the user's registered mobile app or device. The [Guardian SDK](/docs/secure/multi-factor-authentication/auth0-guardian) provides methods to parse the data received from the push notification and return a ready-to-use `Notification` instance. The `Notification` instance includes a transaction linking ID, or `txlinkid`, that the mobile application uses to retrieve the consent details from Auth0.

The following code samples are example iOS and Android mobile push notification implementations using the Guardian SDK:

<Tabs>
  <Tab title="iOS">
    ```swift lines
    //implementing UNUserNotificationCenterDelegate
    func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification, withCompletionHandler completionHandler: (UNNotificationPresentationOptions) -> Void) {
        let userInfo = notification.request.content.userInfo
        if let notification = Guardian.notification(from: userInfo) {
             // Implement this function to display the prompt and handle user's consent/rejection.
             handleGuardianNotification(notification: notification)
        }
    }
    ```
  </Tab>

  <Tab title="Android">
    ```kotlin lines
    // at the FCM listener you receive a RemoteMessage
    @Override
    public void onMessageReceived(RemoteMessage message) {
        Notification notification = Guardian.parseNotification(message.getData());
        if (notification != null) {
            // you received a Guardian notification, handle it
            handleGuardianNotification(notification);
            return;
        }
        /* handle other push notifications you might be using ... */
    }
    ```
  </Tab>
</Tabs>

### Step 5: Mobile application retrieves the consent details

Call the Guardian SDK from your mobile application to retrieve the consent details i.e. the contents of the `binding_message` from the Auth0 Consent API.

The following code samples are example iOS and Android implementations that retrieve data from the Auth0 Consent API:

<Tabs>
  <Tab title="iOS">
    ```swift lines
    let device: AuthenticationDevice = // the object you obtained during the initial Guardian SDK enrollment process and stored locally
    if let consentId = notification.transactionLinkingId {
        Guardian
            .consent(forDomain: {yourTenantDomain}, device: device)
            .fetch(consentId: consentId, notificationToken: notification.transactionToken)
            .start{result in
                switch result {
                case .success(let payload):
                    // present consent details to the user
                case .failure(let cause):
                    // something went wrong
            }
        }
    }
    ```
  </Tab>

  <Tab title="Android">
    ```kotlin lines
    Enrollment enrollment = // the object you obtained during the initial Guardian SDK enrollment process and stored locally
    if (notification.getTransactionLinkingId() != null) {
        guardian
          .fetchConsent(notification, enrollment)
          .start(new Callback<Enrollment> {
            @Override
            void onSuccess(RichConsent consentDetails) {
                // present consent details to the user 
            }
            @Override
            void onFailure(Throwable exception) {
                // something went wrong 
            }
          });
    }
    ```
  </Tab>
</Tabs>

### Step 6: Mobile application presents the consent details to the user

The Auth0 Consent API responds to the mobile application with the consent details, including the `binding_message`, `scope`, `audience`, and `authorization_details` if configured. The scopes returned to the mobile application are filtered according to your RBAC policy. To learn more, read [Role-Based Access Control](/docs/manage-users/access-control/rbac).

The following code sample is an example response from the Auth0 Consent API:

```json lines
{
  "id": "cns_2309dsfsd098",
  "requested_details": {
    "audience": "https://api.example.com",
    "scope": ["read:profile", "write:profile"],
    "binding_message": "abc123",
    "authorization_details": [
      {
        "type": "money_transfer",
        "instructedAmount": {
          "amount": 2500,
          "currency": "USD"
        },
        "sourceAccount": "xxxxxxxxxxx1234",
        "destinationAccount": "xxxxxxxxxxx9876",
        "beneficiary": "Hanna Herwitz",
        "subject": "A Lannister Always Pays His Debts"
      }
    ]
  },
  "created_at": 1632739200,
  "expires_at": 1632739200
}
```

The mobile application presents the authorization request and/or the consent details with the `authorization_details` to the user in a push notification via the Guardian SDK. The user can accept or decline the authorization request at this point.

### Step 7: Mobile application sends the user response back to Auth0

Depending on whether the user accepts or rejects the authorization request, the mobile application sends the user response back to Auth0.

The following code samples are example iOS and Android implementations that handle the user response:

#### User accepts the authorization request

<Tabs>
  <Tab title="iOS">
    ```swift lines
    Guardian
        .authentication(forDomain: "{yourTenantDomain}", device: device)
        .allow(notification: notification)
        // or reject(notification: notification, withReason: "hacked")
        .start { result in
            switch result {
            case .success:
                // the auth request was successfully rejected
            case .failure(let cause):
                // something failed, check cause to see what went wrong
            }
        }
    ```
  </Tab>

  <Tab title="Android">
    ```kotlin lines
    guardian
        .allow(notification, enrollment)
        .execute(); // or start(new Callback<> ...)
    ```
  </Tab>
</Tabs>

#### User rejects the authorization request

<Tabs>
  <Tab title="iOS">
    ```swift lines
    Guardian
            .authentication(forDomain: "{yourTenantDomain}", device: device)
            .reject(notification: notification)
            // or reject(notification: notification, withReason: "hacked")
            .start { result in
                switch result {
                case .success:
                    // the auth request was successfully rejected
                case .failure(let cause):
                    // something failed, check cause to see what went wrong
                }
            }
    ```
  </Tab>

  <Tab title="Android">
    ```kotlin lines
    guardian
        .reject(notification, enrollment) // or reject(notification, enrollment, reason)
        .execute(); // or start(new Callback<> ...)
    ```
  </Tab>
</Tabs>

### Step 8: Auth0 receives user response after the flow completes

The client application completes the polling upon receiving a response from the `/token` endpoint. A CIBA flow always requires a response, either an approval or decline, from the authorizing user, and existing grants are not checked. This means Auth0 treats every CIBA request as a fresh authorization for the authorizing user.

### Step 9: Auth0 returns access token to client application

If the user rejects the push request, Auth0 returns an error response like the following to the client application:

```json lines
{
    "error": "access_denied",
    "error_description": "The end-user denied the authorization request or it has been expired"
}
```

If the user approves the push request, Auth0 returns an <Tooltip tip="Access Token: Authorization credential, in the form of an opaque string or JWT, used to access an API." cta="View Glossary" href="/docs/glossary?term=access+token">access token</Tooltip> with the `authorization_details` like the following to the client application:

```json lines
{
  "id_token": "...",
  "access_token": "...",
  "expires_in": "...",
  "scope": "$granted_scopes",
  "authorization_details": [{
      "type": "money_transfer", 
      "instructedAmount": {
        "amount": 2500, 
        "currency": "USD"
      }, 
      "sourceAccount": "xxxxxxxxxxx1234", 
      "destinationAccount": "xxxxxxxxxxx9876", 
      "beneficiary": "Hanna Herwitz", 
      "subject": "A Lannister Always Pays His Debts"
    }]
}
```

**Note:** The `id_token` will only be present if the `openid` scope was included in the initial `/bc-authorize` request.

## Query authorization\_details

At compile time, you can query the type and objects of `authorization_details` from the consent details in a strongly typed manner as you would dynamically query JSON:

<Tabs>
  <Tab title="iOS">
    ```swift lines
    let requestedDetails: ConsentRequestedDetails = payload.requestedDetails
    let myAuthorizationDetailsTypes = requestedDetails.authorizationDetails[0].objectValue!;
    let type = myAuthorizationDetailsTypes["type"]?.stringValue // Your pre-registered type value
    let stringProperty = myAuthorizationDetailsTypes["string_property"]?.stringValue
    let boolProperty = myAuthorizationDetailsTypes["bool_property"]?.boolValue
    let numericProperty = myAuthorizationDetailsTypes["numeric_property"]?.doubleValue
    let nestedObjectProperty = myAuthorizationDetailsTypes["nested_property"]?.objectValue
    let nestedArrayProperty = myAuthorizationDetailsTypes["nested_array_property"]?.arrayValue
    ```
  </Tab>

  <Tab title="Android">
    ```kotlin lines
    RichConsentRequestedDetails requestedDetails = consentDetails.getRequestedDetails();
    Map<String, Object> authorizationDetails = requestedDetails.getAuthorizationDetails().get(0);
    String type = (String) myAuthorizationDetailsTypes.get("type");
    String stringProperty = (String) myAuthorizationDetailsTypes.get("string_property");
    boolean booleanProperty = (boolean) myAuthorizationDetailsTypes.get("boolean_property");
    int numericProperty = (int) myAuthorizationDetailsTypes.get("numeric_property");
    Object nestedObjectProperty = myAuthorizationDetailsTypes.get("nested_property");
    List<Object> nestedArrayProperty = (List<Object>) myAuthorizationDetailsTypes.get("nested_array_property");
    ```
  </Tab>
</Tabs>

If you define a custom type to represent your object, you can use the `filterAuthorizationDetailsByType()` function to return all `authorization_details` objects that match the desired type.

The following code sample queries `authorization_details` with the `payment` type:

<Tabs>
  <Tab title="iOS">
    ```swift lines
    // Must implement AuthorizationDetailsType 
    struct Payment : AuthorizationDetailsType { 
    static let type = "payment"; 
    let amount: Double; 
    let currency: String; 
    } 

    ... 

    let requestedDetails: ConsentRequestedDetails = payload.requestedDetails 
    let payments = requestedDetails.filterAuthorizationDetailsByType(Payment.self) 
    let firstPayment = payments.first!
    let type: String = firstPayment.type // "payment" 
    let amount: Double = firstPayment.amount 
    let currency: String = firstPayment.currency
    ```
  </Tab>

  <Tab title="Android">
    ```kotlin lines expandable
    @AuthorizatioDetailsType("payment")
    class Payment {
        private String type;
        private int amount;
        private String currency;

        public Payment(String type, int amount, String currency) {
            this.type = type;
            this.amount = amount;
            this.currency = currency;
        }

        public String getType() {
            return type;
        }

        public int getAmount() {
            return amount;
        }

        public String getCurrency() {
            return currency;
        }
    }

    ...

    RichConsentRequestedDetails requestedDetails = consentDetails.getRequestedDetails();
    List<Payment> payments = requestedDetails.filterAuthorizationDetailsByType(Payment.class);
    Payment firstPayment = payments.get(0);
    String type = firstPayment.getType();
    int amount = firstPayment.getAmount();
    String currency = firstPayment.getCurrency();
    ```
  </Tab>
</Tabs>

`filterAuthorizationDetailsByType()` only returns objects matching the specified `authorization_details` type. As a result, your mobile application should present all relevant `authorization_details` to the user for consent, regardless of their type, to ensure a complete understanding of the request

You can also query the `authorization_details` when the AI agent or application polls the `/oauth/token`endpoint for a response:

```json lines
POST https://$tenant/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=urn:openid:params:grant-type:ciba&
client_id=$client_id&
client_secret=$client_secret&
auth_req_id=$auth_req_id
```

<table class="table">
  <thead>
    <tr>
      <th><strong>Parameters</strong></th>
      <th><strong>Description</strong></th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td><code>grant\_type</code></td>
      <td>Set to the CIBA grant type: <code>urn:openid:params:grant-type:ciba</code></td>
    </tr>

    <tr>
      <td><code>client\_id</code></td>
      <td>Set to the application’s client ID.</td>
    </tr>

    <tr>
      <td><code>client\_secret</code></td>
      <td>Set to the application’s client secret.</td>
    </tr>

    <tr>
      <td><code>auth\_req\_id</code></td>
      <td>Returned from the Auth0 tenant when it acknowledges the CIBA request. References the CIBA request.</td>
    </tr>
  </tbody>
</table>

When the authorizing user approves the request, Auth0 receives the user response, and the CIBA flow completes, returning an access token and `authorization_details` array:

```json lines
{ 
  "access_token": "ey...ZQ", 
  "expires_in": 86400, 
  "authorization_details": [{ 
    "type": "money_transfer", 
    "instructedAmount": {
      "amount": 2500, 
      "currency": "USD"
    }, 
    "sourceAccount": "xxxxxxxxxxx1234", 
    "destinationAccount": "xxxxxxxxxxx9876", 
    "beneficiary": "Hanna Herwitz", 
    "subject": "A Lannister Always Pays His Debts" 
  }], 
  "token_type": "Bearer" 
}
```

## Limitations

Auth0 doesn’t support:

* Accessing or modifying RAR in Actions for CIBA flows.
* Advertising RAR types for clients to discover, which means you need to pre-register clients with the `authorization_details` types they can send.
* Validating RAR objects beyond checking that they have a `type` property that matches allowed types for the API. Your resource server is responsible for the granular validation of the content within `authorization_details`. For more information, see [Configure RAR](/docs/get-started/apis/configure-rich-authorization-requests).

## Learn more

* [Configure Rich Authorization Requests (RAR)](/docs/get-started/apis/configure-rich-authorization-requests)
* [Authorization Code Flow with Rich Authorization Requests (RAR)](/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-rar)
* [Configure Client-Initiated Backchannel Authentication](/docs/get-started/applications/configure-client-initiated-backchannel-authentication)