> ## 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 autenticar usuarios con el flujo de autenticación de canal secundario iniciada por el cliente mediante notificaciones por correo electrónico.

# Notificaciones por correo electrónico con CIBA

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Para usar las funciones de autenticación de canal secundario iniciada por el cliente (CIBA), debes tener un plan Enterprise o un add-on adecuado. Consulta [Auth0 Pricing](https://auth0.com/pricing/) para obtener más información.
</Callout>

Cuando usas notificaciones por correo electrónico con CIBA, el usuario recibe un correo electrónico con un enlace que lo redirige para autenticarse o autorizar una solicitud en el navegador.

Al usar notificaciones por correo electrónico con CIBA, el usuario inicia sesión en el dispositivo de consumo, pero completa la autenticación al hacer clic en un enlace enviado a su dirección de correo electrónico verificada. Cuando el usuario hace clic en el enlace de verificación, se le redirige al navegador, lo que crea una sesión que Auth0 usa para seguir el proceso de autenticación y confirmar la identidad del usuario. Esta sesión es necesaria para conectar el dispositivo de autenticación, en este caso el navegador, con el dispositivo de consumo, como una Smart TV.

El siguiente diagrama explica el flujo completo de CIBA con notificaciones por correo electrónico:

<Frame>
  <img src="https://mintcdn.com/translations/xwVvTWJUElMm5YAK/docs/images/ciba/email_notifications_with_ciba_diagram.png?fit=max&auto=format&n=xwVvTWJUElMm5YAK&q=85&s=62dfcbc9f5680c75b2843be1b4f5134e" alt="" width="1390" height="692" data-path="docs/images/ciba/email_notifications_with_ciba_diagram.png" />
</Frame>

En las siguientes secciones se explica paso a paso cómo funciona la autenticación de usuarios con CIBA mediante notificaciones por correo electrónico.

* [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 Tenant de Auth0 confirma la solicitud de CIBA](#step-2%3A-auth0-tenant-acknowledges-the-ciba-request)
* [Paso 3: La aplicación cliente consulta si hay una respuesta](#step-3%3A-client-application-polls-for-a-response)
* [Paso 4: Auth0 envía un enlace a la dirección de correo electrónico del usuario](#step-4%3A-auth0-sends-a-link-to-the-user’s-email-address)
* [Paso 5: El usuario se autentica en el navegador](#step-5%3A-user-authenticates-in-the-browser)
* [Paso 6: El navegador presenta al usuario los detalles del consentimiento](#step-6%3A-browser-sends-the-user-response-back-to-auth0)
* [Paso 7: Auth0 recibe la respuesta del usuario después de que se completa el flujo](#step-7%3A-auth0-receives-user-response-after-the-flow-completes)
* [Paso 8: Auth0 devuelve el token de acceso a la aplicación cliente](#step-8%3A-auth0-returns-access-token-to-client-application)

<div id="prerequisites">
  ## Requisitos previos
</div>

Para iniciar una solicitud de CIBA por correo electrónico con Auth0, debe:

* [Configurar la autenticación de canal secundario iniciada por el cliente](/es/docs/get-started/applications/configure-client-initiated-backchannel-authentication) para su inquilino y su aplicación, incluidas las [notificaciones por correo electrónico](/es/docs/get-started/applications/configure-client-initiated-backchannel-authentication/#configure-email-notifications).
* Establecer el parámetro `requested_expiry` en un valor entre 301 y 259200 segundos (72 horas). Para obtener más información, consulte [Configurar el canal de notificación](/es/docs/get-started/applications/configure-client-initiated-backchannel-authentication#configure-notification-channel).
* Si usa notificaciones por correo electrónico con CIBA y Rich Authorization Requests (RAR) para la [autorización del usuario](/es/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authorization-with-ciba), [configure la pantalla de consent personalizada](/es/docs/get-started/apis/configure-rich-authorization-requests#set-customized-consent-prompt).

<div id="step-1-client-application-initiates-a-ciba-request">
  ## Paso 1: La aplicación cliente inicia una solicitud de CIBA
</div>

Usa las [API de búsqueda de usuarios](/es/docs/manage-users/user-search) para encontrar al usuario que autoriza para el que deseas iniciar una solicitud de CIBA y obtener su ID de usuario.

Una vez que tengas el ID de usuario del usuario que autoriza, usa la Authentication API o nuestros [SDKs](/es/docs/libraries) para enviar una solicitud de CIBA al endpoint `/bc-authorize`:

<Tabs>
  <Tab title="cURL">
    ```bash lines theme={null}
    curl --location 'https://{YOUR_DOMAIN}.auth0.com/bc-authorize' \
      --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 'scope={SCOPES}' \
      --data-urlencode 'binding_message={BINDING_MESSAGE}'
    ```
  </Tab>

  <Tab title="C#">
    ```csharp lines theme={null}
    var response = await authenticationApiClient.ClientInitiatedBackchannelAuthorization(
                new ClientInitiatedBackchannelAuthorizationRequest()
                {
                    ClientId = "{YOUR_CLIENT_ID}",
                    Scope = "{SCOPES}",
                    ClientSecret = "{YOUR_CLIENT_SECRET}",
                    BindingMessage = "{BINDING_MESSAGE}",
                    LoginHint = new LoginHint()
                    {
                        Format = "iss_sub",
                        Issuer = "https://{YOUR_DOMAIN}.auth0.com/",
                        Subject = "{USER_ID}"
                    }
                }
            );
    ```
  </Tab>

  <Tab title="Go">
    ```go lines theme={null}
    resp, err := authAPI.CIBA.Initiate(context.Background(), ciba.Request{
        ClientID:     mgmtClientID,
        ClientSecret: mgmtClientSecret,
        Scope:        "openid",
        LoginHint: map[string]string{
          "format": "iss_sub",
          "iss":    "https://{YOUR_DOMAIN}.auth0.com/",
          "sub":    "{USER_ID}",
        },
        BindingMessage: "{BINDING_MESSAGE}",
      })
    ```
  </Tab>

  <Tab title="Java">
    ```java lines theme={null}
    //Creación de la instancia de AuthClient
    AuthAPI auth = AuthAPI.newBuilder(domain, clientId, clientSecret).build();

    //Autorización
    Map<String, Object> loginHint = new HashMap<>();
            loginHint.put("format", "iss_sub");
            loginHint.put("iss", "https://{YOUR_DOMAIN}.auth0.com/");
            loginHint.put("sub", "{USER_ID}");

    Request<BackChannelAuthorizeResponse> request = auth.authorizeBackChannel("openid", "{BINDING_MESSAGE}", loginHint);

    BackChannelAuthorizeResponse resp = request.execute().getBody();
    ```
  </Tab>
</Tabs>

| Parámetros         | Descripción                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `tenant`           | Nombre del inquilino. También puede ser un dominio personalizado. Si se usa el formato `iss_sub`, el nombre del inquilino se pasa en el claim `iss`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
| `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`.<br /><br />El scope puede incluir opcionalmente `offline_access` para solicitar un Token de actualización. Sin embargo, para la autorización puntual de una transacción con el flujo de CIBA, no se necesita un token de actualización y no tiene ningún significado en este contexto.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
| `user_id`          | ID de usuario 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 en el claim `sub`.<br /><br />El ID de usuario puede tener un formato distinto según el proveedor externo.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
| `requested_expiry` | La duración máxima, en segundos, durante la que la sesión de CIBA debe ser válida. La expiración solicitada del flujo de 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 de CIBA.<br /><br />El parámetro `requested_expiry` ayuda a determinar qué canal de notificación usa CIBA:<ul><li>Si establece `requested_expiry` en un valor de 300 segundos o menos, CIBA usa el canal de notificaciones push móviles si está habilitado. Si no ha configurado MFA en su inquilino, la solicitud de CIBA falla.</li><li>Si establece `requested_expiry` en un valor de entre 301 y 259200 segundos (72 horas), CIBA usa el canal de notificación por correo electrónico si está habilitado.</li></ul> |
| `binding_message`  | Mensaje legible que se usa para vincular el flujo de 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 `+-_.,:#`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Se aplica un límite de tasa por usuario: al usuario autorizador no se le enviarán más de 5 solicitudes por minuto.
</Callout>

<div id="step-2-auth0-tenant-acknowledges-the-ciba-request">
  ## Paso 2: El Tenant de Auth0 confirma la solicitud de CIBA
</div>

Si el Tenant de Auth0 recibe correctamente la solicitud `POST`, deberías recibir una respuesta que contenga un `auth-req-id` que haga referencia a ella:

```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 si el flujo CIBA se ha completado.

<div id="step-3-client-application-polls-for-a-response">
  ## Paso 3: La aplicación cliente consulta la respuesta
</div>

Use Authentication API o nuestros [SDKs](/es/docs/libraries) 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`:

<Tabs>
  <Tab title="cURL">
    ```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'
    ```
  </Tab>

  <Tab title="C#">
    ```csharp lines theme={null}
    var token = await authenticationApiClient.GetTokenAsync(
                new ClientInitiatedBackchannelAuthorizationTokenRequest()
                {
                    AuthRequestId = response.AuthRequestId,
                    ClientId = "{YOUR_CLIENT_ID}",
                    ClientSecret = "{YOUR_CLIENT_SECRET}"
                }
            );
    ```
  </Tab>

  <Tab title="Go">
    ```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{})
    ```
  </Tab>

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

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

Hasta que el usuario que autoriza 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 sondeos. Si realiza sondeos con demasiada frecuencia, recibirá la siguiente respuesta, donde la descripción varía según el intervalo de retroceso:

```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 hasta el siguiente intervalo (en segundos) antes de consultar el endpoint `/token`.

<div id="step-4-auth0-sends-a-link-to-the-users-email-address">
  ## Paso 4: Auth0 envía un enlace a la dirección de correo electrónico del usuario
</div>

El Servidor de autorización de Auth0 usa `login_hint`, que contiene el ID del usuario que autoriza, para iniciar la autenticación del usuario en el dispositivo de autenticación:

* El Servidor de autorización de Auth0 envía un correo electrónico a la dirección de correo electrónico verificada del usuario.
* El correo electrónico contiene un enlace de verificación en el que el usuario debe hacer clic para autenticarse. El `binding_message` aparece como el código de solicitud.
* El enlace dirige al usuario al navegador mediante una solicitud al endpoint `/bc-verify`, donde el parámetro de consulta `consent` hace referencia a la solicitud CIBA pendiente de consentimiento.

<Frame>
  <img src="https://mintcdn.com/translations/xwVvTWJUElMm5YAK/docs/images/ciba/ciba_with_email_verification_link.png?fit=max&auto=format&n=xwVvTWJUElMm5YAK&q=85&s=7c2806e5d2c53268e0d51640effdd35d" alt="Auth0 envía un correo electrónico a la dirección de correo electrónico verificada del usuario" style={{ width: '300px', height: 'auto' }} width="944" height="1098" data-path="docs/images/ciba/ciba_with_email_verification_link.png" />
</Frame>

<div id="step-5-user-authenticates-in-the-browser">
  ## Paso 5: El usuario se autentica en el navegador
</div>

Si no se encuentra ninguna sesión activa, el enlace de verificación le pedirá al usuario que se autentique. El usuario hace clic en el enlace para continuar con la autenticación.

Para autenticarse, el usuario introduce su dirección de correo electrónico verificada y su contraseña. Debe usar las credenciales correspondientes al parámetro `login_hint` enviado al endpoint `/bc-authorize` cuando la aplicación cliente [inicia una solicitud de CIBA](#step-1%3A-client-application-initiates-a-ciba-request). De lo contrario, se le mostrará un mensaje de error y tendrá que cerrar sesión y volver a intentarlo.

<Frame>
  <img src="https://mintcdn.com/translations/xwVvTWJUElMm5YAK/docs/images/ciba/user_authenticates_in_browser.png?fit=max&auto=format&n=xwVvTWJUElMm5YAK&q=85&s=d2b9e392bf1fe47db2db4205a65523b5" alt="El usuario se autentica en el navegador" style={{ width: '300px', height: 'auto' }} width="636" height="994" data-path="docs/images/ciba/user_authenticates_in_browser.png" />
</Frame>

Al igual que en un flujo de inicio de sesión estándar, el desencadenador `post-login` de Actions se ejecuta en el flujo de CIBA con correo electrónico, lo que permite a los clientes proporcionar lógica personalizada para aplicar políticas de control de acceso o solicitar factores MFA adicionales. Cuando se ejecuta desde un enlace de verificación de CIBA, el valor de `event.transaction.protocol` es `oidc-ciba-web-link`, lo que le permite aplicar reglas personalizadas a este tipo específico de inicio de sesión. Para obtener más información, consulte [Login Trigger](https://auth0.com/docs/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger).

Una vez autenticado, el navegador presenta al usuario los datos de consentimiento de la API de Consent de Auth0, que incluye `binding_message`, `scope` y `audience`. Los alcances se filtran según su política de RBAC. Para obtener más información, consulte [Role-Based Access Control](/es/docs/manage-users/access-control/rbac).

El siguiente ejemplo de código muestra una respuesta de ejemplo de la API de Consent de Auth0:

```json lines theme={null}
{
  "id": "cns_abc123",
  "requested_details": {
    "audience": "https://$tenant.auth0.com/userinfo",
    "scope": ["openid"],
    "binding_message": "21-49-38"
  },
  "created_at": 1746693720
  "expires_at": 1746693750
}
```

En este punto, el usuario puede aceptar o denegar la solicitud de autenticación.

<div id="step-6-browser-sends-the-user-response-back-to-auth0">
  ## Paso 6: El navegador envía la respuesta del usuario de nuevo a Auth0
</div>

El navegador envía la respuesta del usuario de nuevo a Auth0. Según el usuario acepte o rechace la solicitud de autenticación, Auth0 muestra las siguientes pantallas de consentimiento, que debe personalizar [configurando las pantallas de consentimiento](/es/docs/get-started/apis/configure-rich-authorization-requests#set-customized-consent-prompt):

<div id="user-accepts-the-authentication-request">
  ### El usuario acepta la solicitud de autenticación
</div>

<Frame>
  <img src="https://mintcdn.com/translations/xwVvTWJUElMm5YAK/docs/images/ciba/user_accepts_the_authentication_request.png?fit=max&auto=format&n=xwVvTWJUElMm5YAK&q=85&s=ce1d2f84cb81bab9ec88176b7ba41f11" alt="El usuario acepta la solicitud de autenticación" style={{ width: '300px', height: 'auto' }} width="730" height="982" data-path="docs/images/ciba/user_accepts_the_authentication_request.png" />
</Frame>

<div id="user-rejects-the-authentication-request">
  ### El usuario rechaza la solicitud de autenticación
</div>

<Frame>
  <img src="https://mintcdn.com/translations/xwVvTWJUElMm5YAK/docs/images/ciba/user_rejects_authentication_request.png?fit=max&auto=format&n=xwVvTWJUElMm5YAK&q=85&s=cf9b9f25925235ea0221fec5e57da120" alt="El usuario acepta la solicitud de autenticación" style={{ width: '300px', height: 'auto' }} width="774" height="1038" data-path="docs/images/ciba/user_rejects_authentication_request.png" />
</Frame>

<div id="step-7-auth0-receives-user-response-after-the-flow-completes">
  ## Paso 7: Auth0 recibe la respuesta del usuario después de que finaliza el flujo
</div>

La aplicación cliente completa el sondeo al recibir una respuesta del endpoint `/token`. Un flujo CIBA siempre requiere una respuesta del usuario que autoriza, ya sea de aprobación o rechazo, y no se verifican las autorizaciones existentes.

<div id="step-8-auth0-returns-access-token-to-client-application">
  ## Paso 8: Auth0 devuelve el token de acceso a la aplicación cliente
</div>

Si el usuario rechaza la solicitud por correo electrónico, 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 enviada por correo electrónico, Auth0 devuelve a la aplicación cliente un <Tooltip tip="Token de acceso: Credencial de autorización, en forma de cadena opaca o JWT, usada para acceder a una API." cta="Ver glosario" href="/es/docs/glossary?term=access+token">token de acceso</Tooltip> como el siguiente:

```json lines theme={null}
{
    "access_token": "eyJh...",
    "id_token": "eyJh...",
    "expires_in": 86400,
    "scope": "openid",
    "token_type": "Bearer"
}
```

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  `refresh_token` solo estará presente si se incluyó el scope `offline_access` en la solicitud inicial de `/bc-authorize`.
</Callout>

<div id="learn-more">
  ## Más información
</div>

* [Flujo de autenticación de canal secundario iniciado por el cliente](/es/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow)
* [Configurar la autenticación de canal secundario iniciada por el cliente](/es/docs/get-started/applications/configure-client-initiated-backchannel-authentication)