Apprenez à authentifier des utilisateurs avec le flux Client-Initiated Backchannel Authentication en utilisant des notifications push mobiles.
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 pour plus de détails.
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 :
Les sections suivantes expliquent, étape par étape, le fonctionnement de l’authentification des utilisateurs avec CIBA en utilisant des notifications push mobiles.
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.
Étape 1 : L’application cliente initie une requête CIBA
Utilisez les API de recherche d’utilisateurs 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) pour envoyer une requête CIBA au point de terminaison /bc-authorize :
// Création d'une instance AuthClientAuthAPI auth = AuthAPI.newBuilder(domain, clientId, clientSecret).build();// AutoriserMap<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();
Paramètres
Description
tenant
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.
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 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.
scope
Doit inclure openid.
La portée peut, de façon facultative, inclure offline_access 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.
user_id
ID de l’utilisateur autorisant la demande, qui est transmis dans la structure login_hint. Si le format iss_sub est utilisé, alors l’ID de l’utilisateur est transmis dans la revendication sub.
L’ID de l’utilisateur peut avoir un format différent selon le fournisseur externe.
requested_expiry
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 requested_expiry pour définir une expiration personnalisée pour le flux CIBA.
Le paramètre requested_expiry aide à déterminer quel canal de notification CIBA utilise :
Si vous définissez votre requested_expiry 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.
Si vous définissez votre requested_expiry sur une valeur comprise entre 301 et 259200 secondes (72 heures), CIBA utilise le canal de notification par courriel s’il est activé.
binding_message
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 +-_.,:#.
Il existe une limite de débit par utilisateur : l’utilisateur autorisant la demande ne recevra pas plus de 5 requêtes par minute.
Étape 3 : l’application cliente interroge périodiquement pour obtenir une réponse
Utilisez l’Authentication API ou nos SDK pour appeler le point de terminaison /token avec le grant typeurn:openid:params:grant-type:ciba et la valeur auth_req_id que vous avez reçue du point de terminaison /bc-authorize :
Tant que l’utilisateur autorisant n’a pas approuvé la transaction, vous devriez recevoir la réponse suivante :
Copier
{ "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) :
Étape 4 : L’application mobile reçoit la notification push
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.Si vous utilisez une application personnalisée, la trousse de développement logiciel (SDK) 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 :
iOS
Android
Copier
// implémentation de UNUserNotificationCenterDelegatefunc 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) }}
Copier
// dans l'écouteur FCM, vous recevez un RemoteMessage@Overridepublic 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 ... */}
Étape 5 : L’application mobile récupère les détails du consentement
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 :
iOS
Android
Copier
let device: AuthenticationDevice = // l’objet que vous avez obtenu lors du processus d’inscription initial au SDK Guardian et stocké localementif 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 } }}
Copier
Enrollment enrollment = // l’objet que vous avez obtenu lors du processus d’inscription initial au SDK Guardian et stocké localementif (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 } });}
Étape 6 : L’application mobile présente les détails du consentement à l’utilisateur
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.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 :
Étape 7 : L’application mobile renvoie la réponse de l’utilisateur à Auth0
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 :
L’utilisateur accepte la demande d’authentification
iOS
Android
Copier
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é } }
Copier
guardian .allow(notification, enrollment) .execute(); // ou start(new Callback<> ...)
L’utilisateur refuse la demande d’authentification
iOS
Android
Copier
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é } }
Copier
guardian .reject(notification, enrollment) // ou reject(notification, enrollment, reason) .execute(); // ou start(new Callback<> ...)
Étape 8 : Auth0 reçoit la réponse de l’utilisateur après l’achèvement du flux
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.
