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 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 :
Pour initier une requête CIBA poussée, l’utilisateur autorisant doit être inscrit à la en utilisant les notifications poussées. Pour vérifier dans , 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 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.
Étape 1 - L’application client initie une demande CIBA
Utilisez les User Search API (API de recherche d’utilisateurs) 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 pour envoyer une demande CIBA au point de terminaison /bc-authorize :
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 3 - L’application client demande une réponse
Utilisez l’Authentication API ou nos trousses SDK 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 :
Jusqu’à ce que l’utilisateur autorisant la transaction l’approuve, vous devriez recevoir la réponse suivante :
Signaler un code incorrect
Copier
Demander à l'IA
{ "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 :
Signaler un code incorrect
Copier
Demander à l'IA
{"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 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 :
iOS
Android
Signaler un code incorrect
Copier
Demander à l'IA
//implementing UNUserNotificationCenterDelegatefunc 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) }}
Signaler un code incorrect
Copier
Demander à l'IA
// at the FCM listener you receive a RemoteMessage@Overridepublic 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 :
iOS
Android
Signaler un code incorrect
Copier
Demander à l'IA
let device: AuthenticationDevice = // the object you obtained during the initial Guardian SDK enrollment process and stored locallyif 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 } }}
Signaler un code incorrect
Copier
Demander à l'IA
Enrollment enrollment = // the object you obtained during the initial Guardian SDK enrollment process and stored locallyif (notification.getTransactionLinkingId() != null) { guardian .fetchConsent(notification, enrollment) .start(new Callback<Enrollment> { @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 :
É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
iOS
Android
Signaler un code incorrect
Copier
Demander à l'IA
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 } }
Signaler un code incorrect
Copier
Demander à l'IA
guardian .allow(notification, enrollment) .execute(); // or start(new Callback<> ...)
L’utilisateur rejette la demande d’authentification
iOS
Android
Signaler un code incorrect
Copier
Demander à l'IA
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 } }
Signaler un code incorrect
Copier
Demander à l'IA
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 :
Signaler un code incorrect
Copier
Demander à l'IA
{ "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 :