> ## 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 à authentifier des utilisateurs avec le flux Client-Initiated Backchannel Authentication en utilisant des notifications push mobiles.

# Notifications push mobiles avec CIBA

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

Lorsque vous utilisez des notifications push mobiles avec CIBA, l'utilisateur reçoit une notification push pour authentifier ou autoriser une requête sur son appareil mobile inscrit. Vous pouvez envoyer des notifications push mobiles avec CIBA en utilisant l'application Auth0 Guardian ou une application personnalisée intégrée à la Trousse de développement logiciel (SDK) Auth0 Guardian.

Le flux CIBA avec notifications push mobiles authentifie et autorise les utilisateurs sur leur appareil mobile, ce qui évite d'avoir besoin d'un navigateur. Comme l'appareil utilisé pour accéder à la ressource n'exige pas de session de navigateur active, l'utilisateur n'a pas besoin d'être connecté avant qu'une requête CIBA soit déclenchée. Cela garantit aussi que le flux CIBA n'aura pas d'incidence sur les sessions existantes que l'utilisateur pourrait avoir.

Le diagramme suivant explique de bout en bout le flux CIBA avec notifications push mobiles :

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

Les sections suivantes expliquent, étape par étape, le fonctionnement de l'authentification des utilisateurs avec CIBA en utilisant des notifications push mobiles.

* [Prérequis](#prerequisites)
* [Étape 1 : L'application cliente initie 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 pour obtenir une réponse](#step-3%3A-client-application-polls-for-a-response)
* [Étape 4 : L'application mobile reçoit la notification push](#step-4%3A-mobile-application-receives-the-push-notification)
* [Étape 5 : L'application mobile récupère les détails du consentement](#step-5%3A-mobile-application-retrieves-the-consent-details)
* [Étape 6 : L'application mobile présente les détails du consentement à l'utilisateur](#step-6%3A-mobile-application-presents-the-consent-details-to-the-user)
* [Étape 7 : L'application mobile renvoie la réponse de l'utilisateur à Auth0](#step-7%3A-mobile-application-sends-the-user-response-back-to-auth0)
* [Étape 8 : Auth0 reçoit la réponse de l'utilisateur une fois le flux terminé](#step-8%3A-auth0-receives-user-response-after-the-flow-completes)
* [Étape 9 : Auth0 renvoie un jeton d’accès à l'application cliente](#step-9%3A-auth0-returns-access-token-to-client-application)

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

Pour initier une requête push CIBA à l’aide d’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 push mobiles](/docs/fr-CA/get-started/applications/configure-client-initiated-backchannel-authentication/#configure-mobile-push-notifications).
* Définir le paramètre `requested_expiry` sur une valeur, en secondes, de 300 ou moins. Pour en savoir plus, consultez [Configurer le canal de notification](/docs/fr-CA/get-started/applications/configure-client-initiated-backchannel-authentication#configure-notification-channel).

<div id="step-1-client-application-initiates-a-ciba-request">
  ## Étape 1 : L'application cliente initie une requête CIBA
</div>

Utilisez les [API de recherche d'utilisateurs](/docs/fr-CA/manage-users/user-search) pour trouver l'utilisateur qui autorise pour lequel vous souhaitez initier une requête CIBA et obtenir son ID d'utilisateur.

Une fois que vous avez un ID d'utilisateur pour l'utilisateur qui autorise, utilisez l'Authentication API ou nos [Trousses de développement logiciel (SDK)](/docs/fr-CA/libraries) pour envoyer une requête 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 = "openid",
                    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();

    // Autoriser
    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 `iss_sub` est utilisé, alors le nom du tenant est transmis dans la revendication `iss`.</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 un Secret client, un JWT de clé privée ou l’authentification mTLS. Si vous utilisez un JWT de clé privée 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, de façon facultative, inclure <code>offline\_access</code> pour demander un Jeton d’actualisation. Toutefois, pour une autorisation unique d’une transaction avec le flux CIBA, un jeton d’actualisation n’est pas nécessaire et n’a aucune signification dans ce contexte.<br /></td>
    </tr>

    <tr>
      <td><code>user\_id</code></td>
      <td>ID de l’utilisateur autorisant la demande, qui est transmis dans la structure <code>login\_hint</code>. Si le format <code>iss\_sub</code> est utilisé, alors l’ID de l’utilisateur est 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 durée d’expiration demandée pour le flux CIBA est comprise entre 1 et 259200 secondes (72 heures), et sa 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> sur une valeur de 300 secondes ou moins, CIBA utilise le canal de notification poussée 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> sur une valeur comprise entre 301 et 259200 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 l’appareil d’authentification et l’appareil de consommation. Le message de liaison est obligatoire et peut contenir jusqu’à 64 caractères. Utilisez uniquement des caractères alphanumériques et les caractères <code>+-\_.,:#</code>.</td>
    </tr>
  </tbody>
</table>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Il existe une limite de débit par utilisateur : l’utilisateur autorisant la demande 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 requête CIBA
</div>

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

```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 ce dernier jusqu’à l’achèvement du flux CIBA.

<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 [SDK](/docs/fr-CA/libraries) pour appeler le point de terminaison `/token` avec le `grant type` `urn:openid:params:grant-type:ciba` et la valeur `auth_req_id` que vous avez reçue du point de terminaison `/bc-authorize` :

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

  <Tab title="C#">
    ```csharp lines 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 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 intervalle d’attente d’environ cinq secondes pour le sondage (polling). Si vous sondez 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 jusqu’au prochain intervalle (en secondes) avant de sonder de nouveau le point de terminaison `/token`.

<div id="step-4-mobile-application-receives-the-push-notification">
  ## Étape 4 : L'application mobile reçoit la notification push
</div>

Auth0 envoie une notification push à l'application ou à l'appareil mobile enregistré de l'utilisateur par l'entremise de l'application Auth0 Guardian ou d'une application personnalisée intégrée à la [trousse de développement logiciel (SDK) Auth0 Guardian](/docs/fr-CA/secure/multi-factor-authentication/auth0-guardian).

Si vous utilisez une application personnalisée, la [trousse de développement logiciel (SDK) Auth0 Guardian](/docs/fr-CA/secure/multi-factor-authentication/auth0-guardian) fournit des méthodes pour analyser les données reçues de la notification push et renvoyer une instance `Notification` prête à l'emploi. L'instance `Notification` comprend un identifiant de liaison de transaction, ou `txlinkid`, que l'application mobile utilise pour récupérer les détails du consentement à partir d'Auth0.

Les extraits de code suivants sont des exemples d'implémentations de notifications push mobiles iOS et Android utilisant la trousse de développement logiciel (SDK) Guardian :

<Tabs>
  <Tab title="iOS">
    ```swift lines theme={null}
    // implémentation de UNUserNotificationCenterDelegate
    func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification, withCompletionHandler completionHandler: (UNNotificationPresentationOptions) -> Void) {
        let userInfo = notification.request.content.userInfo
        if let notification = Guardian.notification(from: userInfo) {
             // Implémentez cette fonction pour afficher la demande et traiter le consentement ou le refus de l'utilisateur.
             handleGuardianNotification(notification: notification)
        }
    }
    ```
  </Tab>

  <Tab title="Android">
    ```kotlin lines theme={null}
    // dans l'écouteur FCM, vous recevez un RemoteMessage
    @Override
    public void onMessageReceived(RemoteMessage message) {
        Notification notification = Guardian.parseNotification(message.getData());
        if (notification != null) {
            // vous avez reçu une notification Guardian, traitez-la
            handleGuardianNotification(notification);
            return;
        }
        /* traitez les autres notifications push que vous pourriez utiliser ... */
    }
    ```
  </Tab>
</Tabs>

<div id="step-5-mobile-application-retrieves-the-consent-details">
  ## Étape 5 : L’application mobile récupère les détails du consentement
</div>

Votre application Auth0 Guardian ou votre application personnalisée intégrée au SDK Auth0 Guardian récupère les détails du consentement, c’est-à-dire le contenu du champ `binding_message`, à partir de l’API Auth0 Consent.

Si vous utilisez une application personnalisée, les exemples de code suivants sont des implémentations iOS et Android qui récupèrent des données à partir de l’API Auth0 Consent :

<Tabs>
  <Tab title="iOS">
    ```swift lines theme={null}
    let device: AuthenticationDevice = // l’objet que vous avez obtenu lors du processus d’inscription initial au SDK Guardian et stocké localement
    if let consentId = notification.transactionLinkingId {
        Guardian
            .consent(forDomain: {yourTenantDomain}, device: device)
            .fetch(consentId: consentId, notificationToken: notification.transactionToken)
            .start{result in
                switch result {
                case .success(let payload):
                    // présenter les détails du consentement à l’utilisateur
                case .failure(let cause):
                    // un problème est survenu
            }
        }
    }
    ```
  </Tab>

  <Tab title="Android">
    ```kotlin lines theme={null}
    Enrollment enrollment = // l’objet que vous avez obtenu lors du processus d’inscription initial au SDK Guardian et stocké localement
    if (notification.getTransactionLinkingId() != null) {
        guardian
          .fetchConsent(notification, enrollment)
          .start(new Callback<Enrollment> {
            @Override
            void onSuccess(RichConsent consentDetails) {
                // présenter les détails du consentement à l’utilisateur 
            }
            @Override
            void onFailure(Throwable exception) {
                // un problème est survenu 
            }
          });
    }
    ```
  </Tab>
</Tabs>

<div id="step-6-mobile-application-presents-the-consent-details-to-the-user">
  ## Étape 6 : L’application mobile présente les détails du consentement à l’utilisateur
</div>

L’Auth0 Consent API répond à l’application Auth0 Guardian ou à votre application personnalisée intégrée à la Trousse de développement logiciel (SDK) Auth0 Guardian avec les détails du consentement, y compris le `binding_message`, la `scope` et l’`audience`. Les scopes retournés à l’application mobile sont filtrés selon votre politique 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’application mobile présente la demande d’authentification et/ou les détails du consentement à l’utilisateur.

L’exemple de code suivant illustre 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 demande d’authentification à ce moment.

<div id="step-7-mobile-application-sends-the-user-response-back-to-auth0">
  ## Étape 7 : L'application mobile renvoie la réponse de l'utilisateur à Auth0
</div>

L'application Auth0 Guardian ou votre application personnalisée renvoie la réponse de l'utilisateur à Auth0.

Si vous utilisez une application personnalisée intégrée à la Trousse de développement logiciel (SDK) Auth0 Guardian, les extraits de code suivants présentent des implémentations iOS et Android qui gèrent la réponse de l'utilisateur :

<div id="user-accepts-the-authentication-request">
  ### L'utilisateur accepte la demande d'authentification
</div>

<Tabs>
  <Tab title="iOS">
    ```swift lines theme={null}
    Guardian
        .authentication(forDomain: "{yourTenantDomain}", device: device)
        .allow(notification: notification)
        // ou reject(notification: notification, withReason: "hacked")
        .start { result in
            switch result {
            case .success:
                // la demande d’authentification a été rejetée avec succès
            case .failure(let cause):
                // une erreur s’est produite, vérifiez la cause pour comprendre ce qui s’est mal passé
            }
        }
    ```
  </Tab>

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

<div id="user-rejects-the-authentication-request">
  ### L’utilisateur refuse la demande d’authentification
</div>

<Tabs>
  <Tab title="iOS">
    ```swift lines theme={null}
    Guardian
            .authentication(forDomain: "{yourTenantDomain}", device: device)
            .reject(notification: notification)
            // ou reject(notification: notification, withReason: "hacked")
            .start { result in
                switch result {
                case .success:
                    // la demande d’authentification a été rejetée avec succès
                case .failure(let cause):
                    // une erreur s’est produite; vérifiez la cause pour comprendre ce qui s’est passé
                }
            }
    ```
  </Tab>

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

<div id="step-8-auth0-receives-user-response-after-the-flow-completes">
  ## Étape 8 : Auth0 reçoit la réponse de l’utilisateur après l’achèvement du flux
</div>

L’application cliente termine l’interrogation 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-9-auth0-returns-access-token-to-client-application">
  ## Étape 9 : Auth0 renvoie le jeton d’accès à l’application cliente
</div>

 Si l’utilisateur rejette la demande de notification push, Auth0 renvoie à l’application cliente une réponse d’erreur semblable à la suivante :

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

Si l'utilisateur approuve la demande push, Auth0 renvoie à l'application cliente 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> semblable au suivant :

```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">
  ## En savoir plus
</div>

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