> ## Documentation Index > Fetch the complete documentation index at: https://auth0.com/llms.txt > Use this file to discover all available pages before exploring further. # Authentification des utilisateurs avec CIBA > Apprenez à authentifier les utilisateurs à l’aide du flux d’authentification par canal d’appui initié par le client. L’authentification CIBA est actuellement en accès anticipé. Pour activer l’authentification CIBA, communiquez avec votre Gestionnaire de compte technique. L’authentification par canal d’appui initiée par le client (CIBA) ne repose pas sur une application client qui redirige l’utilisateur via le navigateur pour effectuer le processus de connexion/d’authentification. Au lieu de cela, l’application client appelle directement le fournisseur OpenID par le biais d’une demande par canal d’appui pour lancer le flux d’authentification. Le schéma de séquences suivant illustre une mise en œuvre du flux CIBA : Deux éléments sont définis : un utilisateur autorisant et un utilisateur initiant. L’utilisateur autorisant et l’utilisateur initiant peuvent être deux personnes différentes, par exemple un utilisateur qui appelle un centre d’appel et un agent d’un centre d’appel. Dans d’autres cas d’utilisation, il peut s’agir de la même personne, par exemple un utilisateur qui s’authentifie auprès d’un kiosque de vente au détail ou d’un autre appareil connecté. Les sections suivantes expliquent étape par étape comment fonctionne l’authentification de l’utilisateur avec le flux CIBA : * [Conditions préalables](#prerequisites) * [Étape 1 - L’application client initie une demande CIBA](#step-1-client-application-initiates-a-ciba-request) * [Étape 2 - Le locataire Auth0 accuse réception de la demande CIBA](#step-2-auth0-tenant-acknowledges-the-ciba-request) * [Étape 3 - L’application client demande une réponse](#step-3-client-application-polls-for-a-response) * [Étape 4 - L’application mobile reçoit la notification poussée](#step-4-mobile-application-receives-the-push-notification) * [Étape 5 - L’application mobile récupère les détails du consentement](#step-5-mobile-application-retrieves-the-consent-details) * [Étape 6 - L’application mobile présente les détails du consentement à l’utilisateur](#step-6-mobile-application-presents-the-consent-details-to-the-user) * [Étape 7 - L’application mobile envoie la réponse de l’utilisateur à Auth0](#step-7-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-auth0-receives-user-response-after-the-flow-completes) ## Conditions préalables Pour initier une requête CIBA poussée, l’utilisateur autorisant doit être inscrit à la MFA en utilisant les notifications poussées. Pour vérifier dans Auth0 Dashboard, naviguez vers **User Management (Gestion des utilisateurs) > Users (Utilisateurs)** et cliquez sur l’utilisateur : Si vous avez défini l’authentification multifacteur (MFA) comme obligatoire pour votre locataire, les utilisateurs sont invités à s’inscrire à la MFA lors de leur prochaine connexion. Vous pouvez également utiliser des [Actions](https://auth0.com/blog/using-actions-to-customize-your-mfa-factors/) pour demander l’inscription à la MFA. Les notifications poussées pour la MFA sont généralement mises en œuvre dans une application mobile personnalisée qui intègre la trousse SDK Guardian. Pour en savoir plus, lisez [Configurer une authentification par canal d’appui initiée par le client](/docs/fr-ca/get-started/applications/configure-client-initiated-backchannel-authentication). ## Étape 1 - L’application client initie une demande CIBA Utilisez les [User Search API (API de recherche d’utilisateurs)](https://auth0.com/docs/manage-users/user-search) pour trouver l’utilisateur autorisé pour lequel vous souhaitez lancer une demande CIBA et obtenir son identifiant utilisateur. Une fois que vous avez l’identifiant de l’utilisateur autorisant, utilisez l’Authentication API ou nos [trousses SDK](/docs/fr-ca/libraries) pour envoyer une demande CIBA au point de terminaison `/bc-authorize` : ```bash lines theme={null} curl --location 'https://$tenant.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://$tenant.auth0.com/", "sub": "$user_id" }' \   --data-urlencode 'scope=$scope' \   --data-urlencode 'binding_message=$binding_message' ``` ```csharp lines theme={null} var response = await authenticationApiClient.ClientInitiatedBackchannelAuthorization( new ClientInitiatedBackchannelAuthorizationRequest() { ClientId = "your-client-id", Scope = "openid", ClientSecret = "your-client-secret", BindingMessage = "your-binding-message", LoginHint = new LoginHint() { Format = "iss_sub", Issuer = "your-issuer-domain", Subject = "auth0|user-id-here" } } ); ``` ```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": "your-issuer-domain", "sub": "auth0|user-id-here", }, BindingMessage: "TEST-BINDING-MESSAGE", }) ``` ```java lines theme={null} //Creating AuthClient Instance AuthAPI auth = AuthAPI.newBuilder(domain, clientId, clientSecret).build(); //Authorize Map loginHint = new HashMap<>(); loginHint.put("format", "iss_sub"); loginHint.put("iss", "your-issuer-domain"); loginHint.put("sub", "auth0|user-id-here"); Request request = auth.authorizeBackChannel("openid", "your-binding-message", loginHint); BackChannelAuthorizeResponse resp = request.execute().getBody(); ``` | Parameters | Description | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TENANT | Nom du locataire. Il peut également s’agir d’un domaine personnalisé. | | CLIENT ID | ID client de l’application | | CLIENT SECRET | Méthode d’authentification du client utilisée pour l’authentification de l’utilisateur avec CIBA, telle que Secret Client, Clé privée JWT ou Authentification mTLS. | | SCOPE | Doit inclure un `openid`.

La permission peut inclure `offline_access` en option pour demander un jeton d’actualisation. Cependant, pour l’autorisation à usage 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. | | USER ID | Identifiant utilisateur pour l’utilisateur faisant autorité qui est passé dans la structure `login_hint`.

L’identifiant utilisateur d’une connexion fédérée peut avoir un format différent. | | EXPIRY | L’expiration demandée du flux CIBA est comprise entre 1 et 300 secondes, et elle est par défaut de 300 secondes. | | BINDING MESSAGE | Message utilisé pour lier le flux CIBA entre les dispositifs d’authentification et de consommation. Le message de liaison est requis et peut contenir jusqu’à 64 caractères. Utilisez uniquement les caractères alphanumériques et `+-_.,:#` | | AUDIENCE | Identifiant unique du public pour un jeton émis. | Il existe une limite anti-attaques spécifique à l’utilisateur, selon laquelle l’utilisateur autorisé ne recevra pas plus de 5 demandes par minute. ## Étape 2 - Le locataire Auth0 accuse réception de la demande CIBA Si le locataire Auth0 reçoit avec succès la requête POST, vous devriez recevoir une réponse contenant un `auth-req-id` qui 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 vérifier l’achèvement du flux CIBA. ## Étape 3 - L’application client demande une réponse Utilisez l’Authentication API ou nos [trousses SDK](/docs/fr-ca/libraries) pour appeler le point de terminaison `/token` en utilisant le type d’autorisation `urn:openid:params:grant-type:ciba` et le `auth_req_id` que vous avez reçu du point de terminaison `/bc-authorize` : ```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' ``` ```csharp lines theme={null} var token = await authenticationApiClient.GetTokenAsync( new ClientInitiatedBackchannelAuthorizationTokenRequest() { AuthRequestId = response.AuthRequestId, ClientId = "your-client-id", ClientSecret = "your-client-secret" } ); ``` ```go lines theme={null} token, err := authAPI.OAuth.LoginWithGrant(context.Background(), "urn:openid:params:grant-type:ciba", url.Values{ "auth_req_id": []string{resp.AuthReqID}, "client_id": []string{clientID}, "client_secret": []string{clientSecret}, }, oauth.IDTokenValidationOptions{}) ``` ```java lines theme={null} Request tokenRequest = auth.getBackChannelLoginStatus(authReqId, "grant-type"); BackChannelTokenResponse tokenResponse = tokenRequest.execute().getBody(); ``` Jusqu’à ce que l’utilisateur autorisant la transaction l’approuve, vous devriez recevoir la réponse suivante : ```json lines theme={null} {     "error": "authorization_pending",     "error_description": "The end-user authorization is pending" } ``` L’intervalle d’attente pour la demande est d’environ cinq secondes. Si vous interrogez trop fréquemment, vous recevrez la réponse suivante, dont la description varie en fonction de l’intervalle d’attente : ```json lines theme={null} { "error": "slow_down", "error_description": "You are polling faster than allowed. Try again in 10 seconds." } ``` Pour résoudre l’erreur, attendez le prochain intervalle (en secondes) pour interroger le point de terminaison `/token`. ## Étape 4 - L’application mobile reçoit la notification poussée Auth0 envoie une notification poussée à l’application mobile ou à l’appareil enregistré de l’utilisateur. La [trousse SDK Guardian](/docs/fr-ca/secure/multi-factor-authentication/auth0-guardian) fournit des méthodes pour analyser les données reçues de la notification poussée et retourner 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 auprès d’Auth0. Les exemples de code suivants sont des exemples d’implémentations de notifications poussées mobiles iOS et Android utilisant la trousse SDK Guardian : ```swift lines theme={null} //implementing 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) { // Implement this function to display the prompt and handle user's consent/rejection. handleGuardianNotification(notification: notification) } } ``` ```java lines theme={null} // at the FCM listener you receive a RemoteMessage @Override public void onMessageReceived(RemoteMessage message) {     Notification notification = Guardian.parseNotification(message.getData());     if (notification != null) {         // you received a Guardian notification, handle it         handleGuardianNotification(notification);         return;     }     /* handle other push notifications you might be using ... */ } ``` ## Étape 5 - L’application mobile récupère les détails du consentement Appelez la trousse SDK Guardian à partir de votre application mobile pour récupérer les détails du consentement, c’est-à-dire le contenu de `binding_message` depuis l’Auth0 Consent API. Les exemples de code suivants sont des exemples d’implémentations iOS et Android qui récupèrent les données depuis Auth0 Consent API : ```swift lines theme={null} let device: AuthenticationDevice = // the object you obtained during the initial Guardian SDK enrollment process and stored locally 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):                 // present consent details to the user             case .failure(let cause):                 // something went wrong         }     } } ``` ```java lines theme={null} Enrollment enrollment = // the object you obtained during the initial Guardian SDK enrollment process and stored locally if (notification.getTransactionLinkingId() != null) {     guardian       .fetchConsent(notification, enrollment)       .start(new Callback {         @Override         void onSuccess(RichConsent consentDetails) {             // present consent details to the user          }         @Override         void onFailure(Throwable exception) {             // something went wrong          }       }); } ``` ## Étape 6 - L’application mobile présente les détails du consentement à l’utilisateur L’Auth0 Consent API envoie à l’application mobile une réponse contenant le `binding_message` ou les détails du consentement. L’application mobile présente la demande d’authentification et/ou les détails du consentement à l’utilisateur. L’exemple de code suivant est un exemple de 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 stade. ## Étape 7 - L’application mobile envoie la réponse de l’utilisateur à Auth0 Selon que l’utilisateur accepte ou rejette la demande d’authentification, l’application mobile renvoie la réponse de l’utilisateur à Auth0. Les exemples de code suivants sont des implémentations iOS et Android qui traitent la réponse de l’utilisateur : ### L’utilisateur accepte la demande d’authentification ```swift lines theme={null} Guardian .authentication(forDomain: "{yourTenantDomain}", device: device) .allow(notification: notification) // or reject(notification: notification, withReason: "hacked") .start { result in switch result { case .success: // the auth request was successfully rejected case .failure(let cause): // something failed, check cause to see what went wrong } } ``` ```java lines theme={null} guardian     .allow(notification, enrollment)     .execute(); // or start(new Callback<> ...) ``` ### L’utilisateur rejette la demande d’authentification ```swift lines theme={null} Guardian .authentication(forDomain: "{yourTenantDomain}", device: device) .reject(notification: notification) // or reject(notification: notification, withReason: "hacked") .start { result in switch result { case .success: // the auth request was successfully rejected case .failure(let cause): // something failed, check cause to see what went wrong } } ``` ```java lines theme={null} guardian .reject(notification, enrollment) // or reject(notification, enrollment, reason) .execute(); // or start(new Callback<> ...) ``` ## Étape 8 - Auth0 reçoit la réponse de l’utilisateur une fois le flux terminé L’application client termine l’interrogation après avoir reçu une réponse du point de terminaison `/token`. Un flux CIBA nécessite toujours une réponse, soit une approbation, soit un refus, de la part de l’utilisateur qui a donné l’autorisation, et les autorisations existantes ne sont pas vérifiées. Si l’utilisateur rejette la requête poussée, vous devriez recevoir la réponse suivante : ```json lines theme={null} {     "error": "access_denied",     "error_description": "The end-user denied the authorization request or it has been expired" } ``` Si l’utilisateur approuve la requête poussée, vous devriez recevoir la réponse suivante : ```json lines theme={null} { "access_token": "eyJh...", "id_token": "eyJh...", "expires_in": 86400, "scope": "openid", "token_type": "Bearer" } ``` ## En savoir plus * [Flux d’authentification par canal d’appui initié par le client](/docs/fr-ca/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow) * [Configurer l’authentification par canal d’appui initiée par le client](/docs/fr-ca/get-started/applications/configure-client-initiated-backchannel-authentication)