> ## Documentation Index > Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Aprende a usar Rich Authorization Requests con el flujo backchannel iniciado por el cliente. # Autorización del usuario con CIBA Para usar las funciones de autenticación backchannel iniciada por el cliente (CIBA), debes tener un plan Enterprise o un complemento adecuado. Consulta [Auth0 Pricing](https://auth0.com/pricing/) para obtener más información. [autenticación backchannel iniciada por el cliente (CIBA)](/es/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow) es una especificación de OAuth 2.0 que permite que una aplicación cliente inicie un flujo de autenticación y/o flujo de autorización sin requerir interacción directa del usuario en la aplicación que inicia el flujo. [Rich Authorization Requests (RAR)](/es/docs/get-started/apis/configure-rich-authorization-requests) es una extensión de OAuth 2.0 que permite a las aplicaciones cliente solicitar permisos más complejos, más allá de los alcances estándar de OAuth 2.0, en una solicitud de autorización. Puedes usar CIBA con RAR para pasar datos de autorización granular al Servidor de autorización en una solicitud backchannel. El parámetro `authorization_details` contiene detalles sobre la solicitud que puedes usar para personalizar una pantalla de consentimiento y mostrárselos al usuario. Puedes autorizar usuarios con CIBA usando los siguientes canales de notificación: * [Notificaciones push móviles](/es/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/mobile-push-notifications-with-ciba) mediante la aplicación Auth0 Guardian y una aplicación personalizada integrada con el SDK de Auth0 Guardian. * [Notificaciones por correo electrónico](/es/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/email-notifications-with-ciba), que requieren configurar una pantalla de consentimiento personalizada.
## Casos de uso comunes
Use RAR con el flujo de CIBA en casos de uso que requieran un control más detallado sobre el acceso a los recursos. Entre los casos de uso más comunes se incluyen: 1. Una aplicación de pagos pide al usuario que confirme una transferencia de dinero. `authorization_details` se puede personalizar para mostrar los detalles de la transacción. 2. Un agente de IA muestra al usuario los detalles de una cita médica reprogramada. `authorization_details` se puede personalizar para mostrar la nueva hora y fecha.
## Cómo funciona
El flujo de autorización de usuario con CIBA es similar al flujo de autenticación de usuario con CIBA, en el que la compatibilidad con RAR permite a los clientes pasar `authorization_details` al Servidor de autorización a través del endpoint `/bc-authorize`. El siguiente diagrama de secuencia explica el flujo completo de autorización de usuario con CIBA de extremo a extremo: En las siguientes secciones se explica paso a paso cómo funciona la autorización de usuario con CIBA. * [Requisitos previos](#prerequisites) * [Paso 1: La aplicación cliente inicia una solicitud de CIBA](#step-1%3A-client-application-initiates-a-ciba-request) * [Paso 2: El inquilino de Auth0 confirma la solicitud de CIBA](#step-2%3A-auth0-tenant-acknowledges-the-ciba-request) * [Paso 3: La aplicación cliente sondea para obtener una respuesta](#step-3%3A-client-application-polls-for-a-response) * [Paso 4: El dispositivo de autenticación recibe la notificación push](#step-4%3A-authentication-device-receives-the-notification) * [Paso 5: El dispositivo de autenticación recupera los detalles del consentimiento](#step-5%3A-authentication-device-retrieves-the-consent-details) * [Paso 6: El dispositivo de autenticación presenta al usuario los detalles del consentimiento](#step-6%3A-authentication-device-presents-the-consent-details-to-the-user) * [Paso 7: El dispositivo de autenticación envía la respuesta del usuario a Auth0](#step-7%3A-authentication-device-sends-the-user-response-back-to-auth0) * [Paso 8: Auth0 recibe la respuesta del usuario una vez completado el flujo](#step-8%3A-auth0-receives-user-response-after-the-flow-completes) * [Paso 9: Auth0 devuelve el token de acceso a la aplicación cliente](#step-9%3A-auth0-returns-access-token-to-client-application)
## Requisitos previos
Para iniciar una solicitud de CIBA con Auth0, debe: * [Configurar la autenticación backchannel iniciada por el cliente](/es/docs/get-started/applications/configure-client-initiated-backchannel-authentication) para su inquilino y su aplicación, incluido su [canal de notificación](/es/docs/get-started/applications/configure-client-initiated-backchannel-authentication#configure-notification-channel). * [Configurar Rich Authorization Requests](/es/docs/get-started/apis/configure-rich-authorization-requests) para su servidor de recursos, lo que incluye registrar sus tipos de `authorization_details`. * Si usa notificaciones por correo electrónico con CIBA y RAR, [configure una pantalla de consentimiento personalizada](/es/docs/get-started/apis/configure-rich-authorization-requests#set-customized-consent-prompt).
## Paso 1: La aplicación cliente inicia una solicitud de CIBA
Utilice las [API de búsqueda de usuarios](/es/docs/manage-users/user-search) para encontrar al usuario que debe autorizar la solicitud para el que desea iniciar una solicitud de CIBA y obtener su ID de usuario. Una vez que tenga el ID del usuario que debe autorizar la solicitud, utilice la [Authentication API](https://auth0.com/docs/api/authentication/login/start-back-channel-login) para enviar una solicitud de CIBA con `authorization_details` al endpoint `/bc-authorize`: ```bash lines theme={null} curl --location 'https://{YOUR_DOMAIN}.auth0.com/bc-authorize' \ --request POST \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'client_id={YOUR_CLIENT_ID}' \ --data-urlencode 'client_secret={YOUR_CLIENT_SECRET}' \ --data-urlencode 'login_hint={ "format": "iss_sub", "iss": "https://{YOUR_DOMAIN}.auth0.com/", "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" }]' ``` | Parámetros | Descripción | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `tenant` | Nombre del inquilino que se pasa dentro de la estructura `login_hint`. También puede ser un dominio personalizado. Si se usa el formato `iss_sub`, el nombre del inquilino se pasa dentro del claim `iss`.

**Ejemplo**: `login_hint={"format": "iss_sub", "iss": "https://{YOUR_DOMAIN}.auth0.com/", "sub":"{USER_ID"}` | | `client_id` | Identificador de la aplicación cliente. | | `client_secret` | Método de autenticación del cliente que se usa para la autenticación del usuario con CIBA, como Secreto del cliente, Private Key JWT o autenticación mTLS. Si usa Private Key JWT o mTLS, no necesita incluir el secreto del cliente. | | `scope` | Debe incluir `openid`.

El scope puede incluir opcionalmente `offline_access` para solicitar un Token de actualización. Sin embargo, para la autorización única de una transacción con el flujo CIBA, no se necesita un Token de actualización y no tiene ningún significado en este contexto. | | `user_id` | ID del usuario autorizador que se pasa dentro de la estructura `login_hint`. Si se usa el formato `iss_sub`, el ID de usuario se pasa dentro del claim `sub`.

**Ejemplo**: `login_hint={"format": "iss_sub", "iss": "https://{YOUR_DOMAIN}.auth0.com/", "sub":"{USER_ID}"}`

El ID de usuario puede tener un formato diferente según el proveedor externo. | | `requested_expiry` | La expiración solicitada del flujo CIBA debe estar entre 1 y 259200 segundos (72 horas), y el valor predeterminado es 300 segundos. Incluya el parámetro `requested_expiry` para establecer una expiración personalizada para el flujo CIBA.

El parámetro `requested_expiry` ayuda a determinar qué canal de notificación usa CIBA: | | `binding_message` | Mensaje legible usado para vincular el flujo CIBA entre los dispositivos de autenticación y de consumo. El mensaje de vinculación es obligatorio y puede tener hasta 64 caracteres. Use solo caracteres alfanuméricos y `+-_.,:#` | | `audience` | Identificador único de la audiencia del token emitido. | | `authorization_details` | Una matriz JSON opcional de objetos que describe los permisos que se van a autorizar. Debe registrar el valor `type` de cada objeto en el servidor de recursos mediante el parámetro `authorization_details` del servidor de recursos. Para obtener más información, consulte [Configure Rich Authorization Requests](/es/docs/get-started/apis/configure-rich-authorization-requests). |
## Paso 2: El inquilino de Auth0 confirma la solicitud CIBA
Si el inquilino de Auth0 recibe correctamente la solicitud `POST`, deberías recibir una respuesta que contenga un `auth-req-id` que haga referencia a la solicitud: ```json lines theme={null} {     "auth_req_id": "eyJh...",     "expires_in": 300,     "interval": 5 } ``` El valor `auth_req_id` se envía al endpoint `/token` para consultar periódicamente si el flujo CIBA se ha completado.
## Paso 3: La aplicación cliente consulta periódicamente si hay una respuesta
Utilice la [Authentication API](https://auth0.com/docs/api/authentication/login/start-back-channel-login) para llamar al endpoint `/token` con el grant type `urn:openid:params:grant-type:ciba` y el `auth_req_id` que recibió del endpoint `/bc-authorize`: ```bash lines theme={null} curl --location 'https://{YOUR_DOMAIN}.auth0.com/oauth/token' \   --header 'Content-Type: application/x-www-form-urlencoded' \   --data-urlencode 'client_id={YOUR_CLIENT_ID}' \   --data-urlencode 'client_secret={YOUR_CLIENT_SECRET}' \   --data-urlencode 'auth_req_id={AUTH_REQ_ID}' \   --data-urlencode 'grant_type=urn:openid:params:grant-type:ciba' ``` ```csharp lines theme={null} var token = await authenticationApiClient.GetTokenAsync( new ClientInitiatedBackchannelAuthorizationTokenRequest() { AuthRequestId = response.AuthRequestId, ClientId = "your-client-id", ClientSecret = "your-client-secret" } ); ``` ```go lines theme={null} 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{}) ``` ```java lines theme={null} Request tokenRequest = auth.getBackChannelLoginStatus(authReqId, "grant-type"); BackChannelTokenResponse tokenResponse = tokenRequest.execute().getBody(); ``` Hasta que el usuario que debe autorizar apruebe la transacción, debería recibir la siguiente respuesta: ```json lines theme={null} {     "error": "authorization_pending",     "error_description": "La autorización del usuario final está pendiente" } ``` Hay un intervalo de espera de aproximadamente cinco segundos entre cada sondeo. Si realiza sondeos con demasiada frecuencia, recibirá la siguiente respuesta, donde la descripción varía según el intervalo de espera progresiva: ```json lines theme={null} { "error": "slow_down", "error_description": "You are polling faster than allowed. Try again in 10 seconds." "interval": 10 } ``` Para resolver el error, espere al siguiente intervalo (en segundos) antes de volver a consultar el endpoint `/token`.
## Paso 4: El dispositivo de autenticación recibe la notificación
Según el canal de notificación, Auth0 envía una notificación al dispositivo de autenticación: * [Notificación push móvil](/es/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/mobile-push-notifications-with-ciba#step-4%3A-mobile-application-receives-the-push-notification): Auth0 la envía a la aplicación Auth0 Guardian o a una aplicación móvil personalizada integrada con el SDK de Auth0 Guardian. * [Notificación por correo electrónico](/es/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/email-notifications-with-ciba#step-4%3A-auth0-sends-a-link-to-the-user’s-email-address): Auth0 la envía a la dirección de correo electrónico verificada del usuario. El dispositivo de autenticación obtiene los detalles del consentimiento, es decir, el contenido de `binding_message`, de la API de consentimiento de Auth0: * [Notificación push móvil](/es/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/mobile-push-notifications-with-ciba#step-5%3A-mobile-application-retrieves-the-consent-details): La aplicación Auth0 Guardian o una aplicación personalizada integrada con el SDK de Auth0 Guardian llama a la API de consentimiento de Auth0 para obtener los detalles del consentimiento. * [Notificación por correo electrónico](/es/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/email-notifications-with-ciba#step-5%3A-user-authenticates-in-the-browser): Cuando el usuario hace clic en el enlace de verificación, se le redirige al navegador, que obtiene los detalles del consentimiento de la API de consentimiento de Auth0. La API de consentimiento de Auth0 responde al dispositivo de autenticación con los detalles del consentimiento, incluidos `binding_message`, `scope`, `audience` y `authorization_details`, si están configurados. Los alcances que se devuelven a la aplicación móvil se filtran de acuerdo con su política de RBAC. Para obtener más información, consulte [Control de acceso basado en roles](/es/docs/manage-users/access-control/rbac). El siguiente ejemplo de código muestra una respuesta de la API de consentimiento de Auth0: ```json lines theme={null} { "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 } ``` El dispositivo de autenticación presenta al usuario los detalles de consentimiento con `authorization_details`: * [Notificación push móvil](/es/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/mobile-push-notifications-with-ciba#step-6%3A-mobile-application-presents-the-consent-details-to-the-user): La aplicación Auth0 Guardian muestra `authorization_details` en una pantalla de consentimiento mediante una notificación push. * [Notificación por correo electrónico](/es/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/email-notifications-with-ciba#step-6%3A-browser-sends-the-user-response-back-to-auth0): El navegador muestra `authorization_details` en una pantalla de consentimiento personalizada. Para obtener información sobre cómo personalizar la pantalla de consentimiento, consulta [Configurar una pantalla de consentimiento personalizada](/es/docs/get-started/apis/configure-rich-authorization-requests#set-customized-consent-prompt). En este punto, el usuario puede aceptar o rechazar la solicitud de autorización.
## Paso 7: El dispositivo de autenticación envía la respuesta del usuario a Auth0
Después de que el usuario acepta o rechaza la solicitud de autorización, el dispositivo de autenticación envía la respuesta del usuario a Auth0: * [Notificación push móvil](/es/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/mobile-push-notifications-with-ciba#step-7%3A-mobile-application-sends-the-user-response-back-to-auth0): La aplicación Auth0 Guardian o una aplicación personalizada integrada con el SDK de Auth0 Guardian envía la respuesta del usuario a Auth0. * [Notificación por correo electrónico](/es/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/email-notifications-with-ciba#step-6%3A-browser-sends-the-user-response-back-to-auth0): El navegador envía la respuesta del usuario a Auth0.
## Paso 8: Auth0 recibe la respuesta del usuario una vez completado el flujo
La aplicación cliente completa el sondeo al recibir una respuesta del endpoint `/token`. Un flujo de CIBA siempre requiere una respuesta del usuario que autoriza, ya sea de aprobación o de rechazo, y no se comprueban las autorizaciones ya concedidas. Esto significa que Auth0 trata cada solicitud de CIBA como una nueva autorización para el usuario que autoriza.
## Paso 9: Auth0 devuelve el token de acceso a la aplicación cliente
Si el usuario rechaza la solicitud push, Auth0 devuelve a la aplicación cliente una respuesta de error como la siguiente: ```json lines theme={null} {     "error": "access_denied",     "error_description": "El usuario final denegó la solicitud de autorización o ha caducado" } ``` Si el usuario aprueba la solicitud de notificación push, Auth0 devuelve a la aplicación cliente un token de acceso con `authorization_details` como los siguientes: ```json lines theme={null} { "id_token": "...", "access_token": "...", "expires_in": "...", "scope": "{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" }] } ``` El `refresh_token` solo estará presente si el scope `offline_access` se incluyó en la solicitud inicial a `/bc-authorize`.
## Consultar authorization\_details
En tiempo de compilación, puede consultar el tipo y los objetos de `authorization_details` a partir de los detalles de consentimiento de forma segura en cuanto a tipos, igual que consultaría JSON de forma dinámica: ```swift lines theme={null} let requestedDetails: ConsentRequestedDetails = payload.requestedDetails let myAuthorizationDetailsTypes = requestedDetails.authorizationDetails[0].objectValue!; let type = myAuthorizationDetailsTypes["type"]?.stringValue // Su valor de tipo preregistrado 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 ``` ```kotlin lines theme={null} RichConsentRequestedDetails requestedDetails = consentDetails.getRequestedDetails(); Map 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 nestedArrayProperty = (List) myAuthorizationDetailsTypes.get("nested_array_property"); ``` Si define un tipo personalizado para representar su objeto, puede usar la función `filterAuthorizationDetailsByType()` para devolver todos los objetos `authorization_details` que coincidan con el tipo deseado. En la siguiente muestra de código se consulta `authorization_details` con el tipo `payment`: ```swift lines theme={null} // Debe implementar 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 ``` ```kotlin lines expandable theme={null} @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 payments = requestedDetails.filterAuthorizationDetailsByType(Payment.class); Payment firstPayment = payments.get(0); String type = firstPayment.getType(); int amount = firstPayment.getAmount(); String currency = firstPayment.getCurrency(); ``` `filterAuthorizationDetailsByType()` solo devuelve objetos que coinciden con el tipo de `authorization_details` especificado. Como resultado, su aplicación móvil debe presentar al usuario todos los `authorization_details` pertinentes para el consentimiento, independientemente de su tipo, a fin de garantizar una comprensión completa de la solicitud También puede consultar `authorization_details` cuando el agente de IA o la aplicación sondea el endpoint `/oauth/token` para obtener una respuesta: ```bash lines theme={null} curl --request POST \ --url "https://{YOUR_DOMAIN}.auth0.com/oauth/token" \ --header "Content-Type: application/x-www-form-urlencoded" \ --data-urlencode "grant_type=urn:openid:params:grant-type:ciba" \ --data-urlencode "client_id={YOUR_CLIENT_ID}" \ --data-urlencode "client_secret={YOUR_CLIENT_SECRET}" \ --data-urlencode "auth_req_id={AUTH_REQ_ID}" ``` | Parámetros | Descripción | | --------------- | --------------------------------------------------------------------------------------------------------------- | | `grant_type` | Defínalo como el tipo de concesión de CIBA: `urn:openid:params:grant-type:ciba` | | `client_id` | Defínalo como el ID de cliente de la aplicación. | | `client_secret` | Defínalo como el secreto del cliente de la aplicación. | | `auth_req_id` | Lo devuelve el inquilino de Auth0 cuando confirma la solicitud de CIBA. Hace referencia a la solicitud de CIBA. | Cuando el usuario autorizador aprueba la solicitud, Auth0 recibe la respuesta del usuario y el flujo de CIBA se completa, devolviendo un token de acceso y el array `authorization_details`: ```json lines theme={null} { "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" } ```
## Limitaciones
Auth0 no admite: * Modificar RAR en Actions para flujos de CIBA. * Anunciar tipos de RAR para que los clientes puedan descubrirlos, lo que significa que debes prerregistrar a los clientes con los tipos de `authorization_details` que pueden enviar. * Validar objetos RAR más allá de comprobar que tengan una propiedad `type` que coincida con los tipos permitidos para la API. Tu servidor de recursos es responsable de la validación detallada del contenido de `authorization_details`. Para obtener más información, consulta [Configurar RAR](/es/docs/get-started/apis/configure-rich-authorization-requests).
## Más información
* [Configurar Rich Authorization Requests (RAR)](/es/docs/get-started/apis/configure-rich-authorization-requests) * [Flujo de código de autorización con Rich Authorization Requests (RAR)](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-rar) * [Configurar la autenticación backchannel iniciada por el cliente](/es/docs/get-started/applications/configure-client-initiated-backchannel-authentication)