Apprenez comment authentifier des utilisateurs avec le flux Client-Initiated Backchannel Authentication au moyen de notifications par courriel.
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 pour plus de détails.
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 :
Les sections suivantes expliquent étape par étape le fonctionnement de l’authentification des utilisateurs avec CIBA au moyen de notifications par courriel.
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.
Étape 1 : L’application cliente lance une demande CIBA
Utilisez les API 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 pour envoyer une demande CIBA au point de terminaison /bc-authorize :
// Création d'une instance AuthClientAuthAPI auth = AuthAPI.newBuilder(domain, clientId, clientSecret).build();// AutorisationMap<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é, le nom du tenant est alors 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 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.
scope
Doit inclure openid.
La portée peut, en option, inclure offline_access 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.
user_id
ID de l’utilisateur autorisant, qui est transmis dans la structure login_hint. Si le format iss_sub est utilisé, l’ID de l’utilisateur est alors 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 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 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 à 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.
Si vous définissez votre requested_expiry à une valeur entre 301 et 259 200 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 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 +-_.,:#.
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.
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.
Étape 3 : L’application cliente interroge périodiquement le serveur pour obtenir une réponse
Utilisez l’Authentication API ou nos trousses de développement logiciel (SDK) 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 :
Tant que l’utilisateur qui autorise la demande 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 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) :
Étape 4 : Auth0 envoie un lien à l’adresse de courriel de l’utilisateur
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.
Étape 5 : L’utilisateur s’authentifie dans le navigateur
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. Sinon, un message d’erreur s’affiche et l’utilisateur doit se déconnecter et réessayer.
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.L’exemple de code suivant illustre une réponse de l’API de consentement Auth0 :
Étape 6 : Le navigateur renvoie la réponse de l’utilisateur à Auth0
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 :
Étape 7 : Auth0 reçoit la réponse de l’utilisateur une fois le flux terminé
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.
