> ## 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.

> Découvrez comment authentifier les utilisateurs avec le flux Client-Initiated Backchannel Authentication au moyen de notifications par courriel.

# Notifications par courriel avec CIBA

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Pour utiliser les fonctionnalités de Client-Initiated Backchannel Authentication (CIBA), vous devez disposer d’un Enterprise Plan ou d’un module complémentaire approprié. Consultez [Auth0 Pricing](https://auth0.com/pricing/) pour plus de détails.
</Callout>

Lorsque vous utilisez des notifications par courriel avec CIBA, l’utilisateur reçoit un courriel contenant un lien qui le redirige vers son navigateur pour s’authentifier ou autoriser une requête.

Avec les notifications par courriel dans CIBA, l’utilisateur ouvre une session sur l’appareil de consommation, mais termine l’authentification en cliquant sur un lien envoyé à son adresse courriel vérifiée. Lorsque l’utilisateur clique sur le lien de vérification, il est redirigé vers son navigateur, ce qui crée une session qu’Auth0 utilise pour suivre le processus d’authentification et confirmer l’identité de l’utilisateur. Cette session est nécessaire pour faire le lien entre l’appareil d’authentification, dans ce cas-ci le navigateur, et l’appareil de consommation, comme un téléviseur intelligent.

Le diagramme suivant illustre le flux CIBA de bout en bout avec notifications par courriel :

<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>

Les sections suivantes expliquent, étape par étape, comment fonctionne l’authentification de l’utilisateur avec CIBA au moyen de notifications par courriel.

* [Prérequis](#prerequisites)
* [Étape 1 : L’application cliente amorce une requête CIBA](#step-1%3A-client-application-initiates-a-ciba-request)
* [Étape 2 : Le tenant Auth0 accuse réception de la requête CIBA](#step-2%3A-auth0-tenant-acknowledges-the-ciba-request)
* [Étape 3 : L’application cliente interroge périodiquement pour obtenir une réponse](#step-3%3A-client-application-polls-for-a-response)
* [Étape 4 : Auth0 envoie un lien à l’adresse courriel de l’utilisateur](#step-4%3A-auth0-sends-a-link-to-the-user’s-email-address)
* [Étape 5 : L’utilisateur s’authentifie dans le navigateur](#step-5%3A-user-authenticates-in-the-browser)
* [Étape 6 : Le navigateur présente les détails du consentement à l’utilisateur](#step-6%3A-browser-sends-the-user-response-back-to-auth0)
* [Étape 7 : Auth0 reçoit la réponse de l’utilisateur une fois le flux terminé](#step-7%3A-auth0-receives-user-response-after-the-flow-completes)
* [Étape 8 : Auth0 renvoie le jeton d’accès à l’application cliente](#step-8%3A-auth0-returns-access-token-to-client-application)

<div id="prerequisites">
  ## Prérequis
</div>

Pour lancer une requête CIBA par courriel avec Auth0, vous devez :

* [Configure Client-Initiated Backchannel Authentication](/docs/fr-ca/get-started/applications/configure-client-initiated-backchannel-authentication) pour votre tenant et votre application, y compris les [notifications par courriel](/docs/fr-ca/get-started/applications/configure-client-initiated-backchannel-authentication/#configure-email-notifications).
* Définir le paramètre `requested_expiry` sur une valeur comprise entre 301 et 259200 secondes (72 heures). Pour en savoir plus, consultez [Configurer le canal de notification](/docs/fr-ca/get-started/applications/configure-client-initiated-backchannel-authentication#configure-notification-channel).
* Si vous utilisez les notifications par courriel avec CIBA et Rich Authorization Requests (RAR) pour l’[autorisation de l’utilisateur](/docs/fr-ca/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authorization-with-ciba), [configurez l’invite de consentement personnalisée](/docs/fr-ca/get-started/apis/configure-rich-authorization-requests#set-customized-consent-prompt).

<div id="step-1-client-application-initiates-a-ciba-request">
  ## Étape 1 : L’application cliente lance une demande CIBA
</div>

Utilisez les [API User Search](/docs/fr-ca/manage-users/user-search) pour trouver l’utilisateur qui autorise la demande, pour lequel vous souhaitez lancer une demande CIBA, et obtenir son ID utilisateur.

Une fois que vous avez l’ID utilisateur de l’utilisateur qui autorise la demande, utilisez l’API d’authentification ou nos [SDKs](/docs/fr-ca/libraries) pour envoyer une demande CIBA au point de terminaison `/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}
    //Création d’une instance AuthClient
    AuthAPI auth = AuthAPI.newBuilder(domain, clientId, clientSecret).build();

    //Autorisation
    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>

| Paramètres         | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `tenant`           | Nom du tenant. Il peut aussi s’agir d’un domaine personnalisé. Si le format `iss_sub` est utilisé, le nom du tenant est transmis dans la claim `iss`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
| `client_id`        | Identifiant de l’application cliente.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
| `client_secret`    | Méthode d’authentification du client utilisée pour l’authentification de l’utilisateur avec CIBA, comme Client Secret, Private Key JWT ou l’authentification mTLS. Si vous utilisez Private Key JWT ou mTLS, vous n’avez pas besoin d’inclure le client secret.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
| `scope`            | Doit inclure `openid`.<br /><br />Le scope peut aussi inclure `offline_access` pour demander un refresh token. Toutefois, dans le cas d’une autorisation ponctuelle d’une transaction avec le CIBA Flow, un refresh token n’est pas nécessaire et n’a aucune utilité dans ce contexte.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
| `user_id`          | ID de l’utilisateur autorisant, transmis dans la structure `login_hint`. Si le format `iss_sub` est utilisé, l’ID de l’utilisateur est transmis dans la claim `sub`.<br /><br />L’ID de l’utilisateur peut avoir un format différent selon le fournisseur externe.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
| `requested_expiry` | La durée maximale, en secondes, pendant laquelle la session CIBA doit rester valide. La durée d’expiration demandée pour le CIBA Flow doit être comprise entre 1 et 259200 secondes (72 heures), et la valeur par défaut est de 300 secondes. Incluez le paramètre `requested_expiry` pour définir une durée d’expiration personnalisée pour le CIBA Flow.<br /><br />Le paramètre `requested_expiry` aide à déterminer quel canal de notification CIBA utilise :<ul><li>Si vous définissez `requested_expiry` à 300 secondes ou moins, CIBA utilise le canal de notification push mobile s’il est activé. Si MFA n’est pas configuré pour votre tenant, la CIBA request échoue.</li><li>Si vous définissez `requested_expiry` à une valeur comprise entre 301 et 259200 secondes (72 heures), CIBA utilise le canal de notification par courriel s’il est activé.</li></ul> |
| `binding_message`  | Message lisible par une personne servant à lier le CIBA Flow entre les appareils d’authentification et de consommation. Le message de liaison est obligatoire et peut contenir jusqu’à 64 caractères. Utilisez uniquement des caractères alphanumériques et `+-_.,:#`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Il existe une limite de débit propre à l’utilisateur selon laquelle l’utilisateur autorisant ne recevra pas plus de 5 requêtes par minute.
</Callout>

<div id="step-2-auth0-tenant-acknowledges-the-ciba-request">
  ## Étape 2 : le tenant Auth0 confirme la réception de la requête CIBA
</div>

Si le tenant Auth0 reçoit bien la requête `POST`, vous devriez recevoir une réponse contenant un `auth-req-id` qui renvoie à la requête :

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

La valeur `auth_req_id` est transmise au endpoint `/token` pour vérifier périodiquement si le CIBA flow est terminé.

<div id="step-3-client-application-polls-for-a-response">
  ## Étape 3 : L’application cliente interroge périodiquement pour obtenir une réponse
</div>

Utilisez l’Authentication API ou nos [SDKs](/docs/fr-ca/libraries) pour envoyer une requête au point de terminaison `/token` à l’aide du type d’octroi `urn:openid:params:grant-type:ciba` et de l’`auth_req_id` que vous avez reçu du point de terminaison `/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>

Tant que l’utilisateur autorisant n’a pas approuvé la transaction, vous devriez recevoir la réponse suivante :

```json lines theme={null}
{
    "error": "authorization_pending",
    "error_description": "L'autorisation de l'utilisateur final est en attente"
}
```

Il y a un délai d’attente d’environ cinq secondes entre chaque interrogation périodique. Si vous interrogez le point de terminaison trop fréquemment, vous recevrez la réponse suivante, où la description varie selon l’intervalle de temporisation progressive :

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

Pour corriger l’erreur, attendez le prochain intervalle (en secondes) avant d’interroger le point de terminaison `/token`.

<div id="step-4-auth0-sends-a-link-to-the-users-email-address">
  ## Étape 4 : Auth0 envoie un lien à l’adresse courriel de l’utilisateur
</div>

Auth0 Authorization Server utilise le `login_hint`, qui contient l’ID utilisateur de l’utilisateur autorisant, pour lancer l’authentification de l’utilisateur sur l’appareil d’authentification :

* Auth0 Authorization Server envoie un courriel à l’adresse courriel vérifiée de l’utilisateur.
* Le courriel contient un lien de vérification sur lequel l’utilisateur doit cliquer pour s’authentifier. Le `binding_message` s’affiche comme code de requête.
* Le lien redirige l’utilisateur vers le navigateur au moyen d’une requête à l’endpoint `/bc-verify`, où le paramètre de requête `consent` renvoie à la requête CIBA en attente de consentement.

<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 envoie un courriel à l’adresse courriel vérifiée de l’utilisateur" 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">
  ## Étape 5 : L’utilisateur s’authentifie dans le navigateur
</div>

Si aucune session active n’est trouvée, le lien de vérification demandera à l’utilisateur de s’authentifier. L’utilisateur clique sur le lien pour poursuivre le processus d’authentification.

Pour s’authentifier, l’utilisateur saisit son adresse courriel vérifiée et son mot de passe. L’utilisateur doit utiliser les informations d’authentification fournies au paramètre `login_hint` envoyé au point de terminaison `/bc-authorize` lorsque l’application cliente [initie une demande CIBA](#step-1%3A-client-application-initiates-a-ciba-request). Sinon, un message d’erreur s’affiche et l’utilisateur doit se déconnecter et réessayer.

<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="L’utilisateur s’authentifie dans le navigateur" style={{ width: '300px', height: 'auto' }} width="636" height="994" data-path="docs/images/ciba/user_authenticates_in_browser.png" />
</Frame>

Comme dans un flux de connexion standard, le déclencheur Actions `post-login` s’exécute dans le flux CIBA avec courriel, ce qui permet aux clients d’ajouter une logique personnalisée pour appliquer des politiques de contrôle d’accès ou demander des facteurs MFA supplémentaires. Lorsqu’il est exécuté à partir d’un lien de vérification CIBA, la valeur `event.transaction.protocol` est `oidc-ciba-web-link`, ce qui vous permet d’appliquer des règles personnalisées à ce type précis de connexion. Pour en savoir plus, consultez [Déclencheur de connexion](https://auth0.com/docs/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger).

Une fois l’authentification réussie, le navigateur présente à l’utilisateur les détails de consentement provenant de l’Auth0 Consent API, y compris `binding_message`, `scope` et `audience`. Les `scopes` sont filtrés selon votre politique RBAC. Pour en savoir plus, consultez [Role-Based Access Control](/docs/fr-ca/manage-users/access-control/rbac).

L’exemple de code suivant montre une réponse de l’Auth0 Consent API :

```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
}
```

L’utilisateur peut accepter ou refuser la requête d’authentification à ce stade-ci.

<div id="step-6-browser-sends-the-user-response-back-to-auth0">
  ## Étape 6 : Le navigateur renvoie la réponse de l’utilisateur à Auth0
</div>

Le navigateur renvoie la réponse de l’utilisateur à Auth0. Selon que l’utilisateur accepte ou rejette la requête d’authentification, Auth0 affiche les écrans de consentement suivants, que vous devez personnaliser en [définissant les invites de consentement](/docs/fr-ca/get-started/apis/configure-rich-authorization-requests#set-customized-consent-prompt) :

<div id="user-accepts-the-authentication-request">
  ### L’utilisateur accepte la requête d’authentification
</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="L’utilisateur accepte la requête d’authentification" 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">
  ### L’utilisateur refuse la requête d’authentification
</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="L’utilisateur accepte la requête d’authentification" 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">
  ## Étape 7 : Auth0 reçoit la réponse de l’utilisateur une fois le flux terminé
</div>

L’application cliente met fin à l’interrogation dès qu’elle reçoit une réponse de l’endpoint `/token`. Un flux CIBA exige toujours une réponse — approbation ou refus — de la part de l’utilisateur qui autorise la demande, et les autorisations existantes ne sont pas vérifiées.

<div id="step-8-auth0-returns-access-token-to-client-application">
  ## Étape 8 : Auth0 renvoie le jeton d’accès à l’application cliente
</div>

Si l’utilisateur refuse la demande envoyée par courriel, Auth0 renvoie à l’application cliente une réponse d’erreur semblable à celle-ci :

```json lines theme={null}
{
    "error": "access_denied",
    "error_description": "L'utilisateur final a refusé la demande d'autorisation ou elle a expiré"
}
```

Si l’utilisateur approuve la demande par courriel, Auth0 renvoie à l’application cliente un <Tooltip tip="Jeton d’accès : identifiant d’autorisation, sous la forme d’une chaîne opaque ou d’un JWT, utilisé pour accéder à une API." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=access+token">jeton d’accès</Tooltip> semblable à celui-ci :

```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">
  Le `refresh_token` n’est présent que si la portée `offline_access` a été incluse dans la requête initiale envoyée à `/bc-authorize`.
</Callout>

<div id="learn-more">
  ## Pour en savoir plus
</div>

* [Flux d’authentification par canal secondaire initié par le client](/docs/fr-ca/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow)
* [Configurer l’authentification par canal secondaire initiée par le client](/docs/fr-ca/get-started/applications/configure-client-initiated-backchannel-authentication)