> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.generaltranslation.app/llms.txt
> Use this file to discover all available pages before exploring further.

> Apprenez comment authentifier des 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 Client-Initiated Backchannel Authentication (CIBA), vous devez avoir un plan Enterprise ou un module complémentaire approprié. Consultez la page [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 pour s’authentifier ou autoriser une requête dans le navigateur.

Lorsque vous utilisez des notifications par courriel avec CIBA, l’utilisateur ouvre une session sur l’appareil de consommation, mais complète l’authentification en cliquant sur un lien envoyé à son adresse de courriel vérifiée. Quand 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 combler l’écart entre l’appareil d’authentification, dans ce cas le navigateur, et l’appareil de consommation, comme un téléviseur intelligent.

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

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

Les sections suivantes expliquent étape par étape le fonctionnement de l’authentification des utilisateurs avec CIBA au moyen de notifications par courriel.

* [Prérequis](#prerequisites)
* [Étape 1 : l’application cliente lance 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 sonde pour obtenir une réponse](#step-3%3A-client-application-polls-for-a-response)
* [Étape 4 : Auth0 envoie un lien à l’adresse de 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">
  ## Conditions préalables
</div>

Pour initier une demande CIBA par courriel avec Auth0, vous devez :

* [Configurer 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 259 200 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 les 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 autorisant au nom duquel vous souhaitez lancer une demande CIBA et obtenir son ID d’utilisateur.

Une fois que vous disposez de l’ID de l’utilisateur autorisant, utilisez l’Authentication API 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://{yourDomain}.auth0.com/bc-authorize' \
      --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://{yourDomain}.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 = "<CLIENT_ID>",
                    Scope = "<SCOPES>",
                    ClientSecret = "<CLIENT_SECRET>",
                    BindingMessage = "<BINDING_MESSAGE>",
                    LoginHint = new LoginHint()
                    {
                        Format = "iss_sub",
                        Issuer = "https://{yourDomain}.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://{yourDomain}.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://{yourDomain}.auth0.com/");
            loginHint.put("sub", "<USER_ID>");

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

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

<table class="table">
  <thead>
    <tr>
      <th><strong>Paramètres</strong></th>
      <th><strong>Description</strong></th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td><code>tenant</code></td>
      <td>Nom du tenant. Il peut aussi s’agir d’un domaine personnalisé. Si le format <code>iss\_sub</code> est utilisé, le nom du tenant est alors transmis dans la revendication <code>iss</code>.</td>
    </tr>

    <tr>
      <td><code>client\_id</code></td>
      <td>Identifiant de l’application cliente.</td>
    </tr>

    <tr>
      <td><code>client\_secret</code></td>
      <td>Méthode d’authentification du client utilisée pour l’authentification de l’utilisateur avec CIBA, comme Secret client, Private Key JWT ou authentification mTLS. Si vous utilisez Private Key JWT ou mTLS, vous n’avez pas besoin d’inclure le Secret client.</td>
    </tr>

    <tr>
      <td><code>scope</code></td>
      <td>Doit inclure <code>openid</code>.<br /><br />La portée peut, en option, inclure <code>offline\_access</code> pour demander un Jeton d’actualisation. Cependant, pour une autorisation unique d’une transaction avec le flux CIBA, un Jeton d’actualisation n’est pas requis et n’a aucune utilité dans ce contexte.<br /></td>
    </tr>

    <tr>
      <td><code>user\_id</code></td>
      <td>ID de l’utilisateur autorisant, qui est transmis dans la structure <code>login\_hint</code>. Si le format <code>iss\_sub</code> est utilisé, l’ID de l’utilisateur est alors transmis dans la revendication <code>sub</code>.<br /><br />L’ID de l’utilisateur peut avoir un format différent selon le fournisseur externe.<br /></td>
    </tr>

    <tr>
      <td><code>requested\_expiry</code></td>
      <td>Durée maximale, en secondes, pendant laquelle la session CIBA doit être valide. La valeur d’expiration demandée pour le flux CIBA se situe entre 1 et 259 200 secondes (72 heures), et la valeur par défaut est de 300 secondes. Incluez le paramètre <code>requested\_expiry</code> pour définir une expiration personnalisée pour le flux CIBA.<br /><br />Le paramètre <code>requested\_expiry</code> aide à déterminer quel canal de notification CIBA utilise :<ul><li>Si vous définissez votre <code>requested\_expiry</code> à une valeur de 300 secondes ou moins, CIBA utilise le canal de notification push mobile, s’il est activé. Si vous n’avez pas configuré l’AMF pour votre tenant, la requête CIBA échoue.</li><li>Si vous définissez votre <code>requested\_expiry</code> à une valeur entre 301 et 259 200 secondes (72 heures), CIBA utilise le canal de notification par courriel, s’il est activé.</li></ul></td>
    </tr>

    <tr>
      <td><code>binding\_message</code></td>
      <td>Message lisible par un humain utilisé pour lier le flux CIBA entre les appareils d’authentification et de consommation. Le message de liaison est obligatoire et peut contenir jusqu’à 64 caractères. Utilisez seulement des caractères alphanumériques et <code>+-\_.,:#</code>.</td>
    </tr>
  </tbody>
</table>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Il existe une limite de débit spécifique à chaque 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 accuse réception de la demande 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 fait référence à la demande :

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

La valeur `auth_req_id` est transmise au point de terminaison `/token` pour interroger périodiquement ce point de terminaison et vérifier l’achèvement du flux CIBA.

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

Utilisez l’Authentication API ou nos [trousses de développement logiciel (SDK)](/docs/fr-CA/libraries) pour appeler le point de terminaison `/token` avec le paramètre `grant_type` défini à `urn:openid:params:grant-type:ciba` et 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://{yourDomain}.auth0.com/oauth/token' \
      --header 'Content-Type: application/x-www-form-urlencoded' \
      --data-urlencode 'client_id=<CLIEND_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 theme={null}
    var token = await authenticationApiClient.GetTokenAsync(
                new ClientInitiatedBackchannelAuthorizationTokenRequest()
                {
                    AuthRequestId = response.AuthRequestId,
                    ClientId = "<CLIENT_ID>",
                    ClientSecret = "<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 qui autorise la demande 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. Si vous interrogez trop fréquemment, vous recevrez la réponse suivante, dont la description varie en fonction de l’intervalle de temporisation (backoff) :

```json lines theme={null}
{
"error": "slow_down",
"error_description": "Vous interrogez trop rapidement. Réessayez dans 10 secondes."
"interval": 10
}
```

Pour résoudre 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 de courriel de l’utilisateur
</div>

Le Serveur d’autorisation Auth0 utilise le `login_hint`, qui contient l’id de l’utilisateur qui autorise, pour lancer l’authentification de l’utilisateur sur l’appareil d’authentification :

* Le Serveur d’autorisation Auth0 envoie un courriel à l’adresse de 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 dirige l’utilisateur vers le navigateur au moyen d’une requête au point de terminaison `/bc-verify`, où le paramètre de requête `consent` fait référence à la demande CIBA en attente de consentement.

<Frame>
  <img src="https://mintcdn.com/generaltranslationinc/md6b8ua1hdYa2pM7/docs/images/ciba/ciba_with_email_verification_link.png?fit=max&auto=format&n=md6b8ua1hdYa2pM7&q=85&s=7b8c551dcbddd9424ea54541be146e2e" alt="Auth0 envoie un courriel à l’adresse de 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 invite l’utilisateur à s’authentifier. L’utilisateur clique sur le lien pour poursuivre le processus d’authentification.

Pour s’authentifier, l’utilisateur saisit son adresse de courriel vérifiée et son mot de passe. L’utilisateur doit utiliser les identifiants fournis dans le paramètre `login_hint` envoyé au point de terminaison `/bc-authorize` lorsque l’application cliente [initie une requête 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/generaltranslationinc/md6b8ua1hdYa2pM7/docs/images/ciba/user_authenticates_in_browser.png?fit=max&auto=format&n=md6b8ua1hdYa2pM7&q=85&s=87c6fedddeb1662d616156328410a832" 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>

Une fois authentifié, le navigateur présente à l’utilisateur les détails du consentement provenant de l’API de consentement Auth0, qui comprennent `binding_message`, `scope` et `audience`. Les scopes sont filtrés en fonction de votre stratégie RBAC. Pour en savoir plus, consultez [Contrôle d’accès basé sur les rôles](/docs/fr-CA/manage-users/access-control/rbac).

L’exemple de code suivant illustre une réponse de l’API de consentement 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
}
```

L’utilisateur peut alors accepter ou refuser la demande d’authentification à ce stade.

<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 demande d'authentification, Auth0 affiche les écrans de consentement suivants, que vous devez personnaliser en [configurant les messages de demande 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 demande d’authentification
</div>

<Frame>
  <img src="https://mintcdn.com/generaltranslationinc/md6b8ua1hdYa2pM7/docs/images/ciba/user_accepts_the_authentication_request.png?fit=max&auto=format&n=md6b8ua1hdYa2pM7&q=85&s=ff19dbb878a0ed96ecf19ce3b0924988" alt="L’utilisateur accepte la demande 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 rejette la demande d’authentification
</div>

<Frame>
  <img src="https://mintcdn.com/generaltranslationinc/md6b8ua1hdYa2pM7/docs/images/ciba/user_rejects_authentication_request.png?fit=max&auto=format&n=md6b8ua1hdYa2pM7&q=85&s=cb2422bad333a7c1450ec8d17accb26f" alt="L’utilisateur accepte la demande 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 à la scrutation lorsqu’elle reçoit une réponse du point de terminaison `/token`. Un flux CIBA exige toujours une réponse, soit une approbation soit un refus, de la part de l’utilisateur qui autorise, 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 rejette la demande par courriel, Auth0 renvoie à l’application cliente une réponse d’erreur comme suit :

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

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

```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` ne sera présent que si la portée `offline_access` a été incluse dans la requête `/bc-authorize` initiale.
</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)