Skip to main content
Pour utiliser les fonctionnalités de Client-Initiated Backchannel Authentication (CIBA), vous devez avoir un forfait Enterprise ou un add-on approprié. Consultez la tarification Auth0 pour en savoir plus.
Le flux Client-Initiated Backchannel Authentication (CIBA) est une norme de l’ Foundation qui permet une authentification et une autorisation découplées au moyen de requêtes backchannel sécurisées. Le flux CIBA est conçu pour des cas d’utilisation où l’appareil qui lance une requête (l’appareil de consommation) est différent de l’appareil dont l’utilisateur se sert pour s’authentifier (l’appareil d’authentification). Dans un flux CIBA, il y a deux acteurs :
  • Utilisateur initiateur : l’entité qui lance l’authentification ou l’autorisation sur l’appareil de consommation. Il peut s’agir d’une application backend, d’un utilisateur humain, par exemple un agent du service à la clientèle utilisant une application de service à la clientèle, ou d’un agent IA qui exécute une tâche au nom de l’utilisateur final.
  • Utilisateur autorisant : l’utilisateur final qui reçoit la requête d’authentification ou d’autorisation sur l’appareil d’authentification et donne son consentement.
En dissociant l’authentification et l’autorisation de l’appareil de consommation, l’application cliente peut appeler directement le fournisseur OpenID au moyen d’une requête backchannel. Cela offre une sécurité renforcée, puisque vous pouvez utiliser, avec le flux CIBA, des méthodes plus sécurisées pour l’authentification du client, comme mTLS et Private Key JWT.

​
Cas d’utilisation

Les cas d’utilisation courants du flux CIBA comprennent :
  • Un agent IA utilise des approbations avec intervention humaine pour demander à l’utilisateur l’autorisation d’exécuter une action qu’il a lui-même demandée.
  • Un utilisateur a appelé un centre d’appels, et l’agent qui traite l’appel souhaite accéder, sur son ordinateur, aux renseignements personnels de l’appelant. L’appelant peut y consentir, par exemple, en approuvant une notification push sur son téléphone.
  • Un utilisateur souhaite accéder à un appareil dont les capacités d’entrée sont limitées, comme un vélo que vous pourriez louer en ville ou une borne libre-service dans un commerce de détail.
  • Un utilisateur lance une transaction sensible sur un appareil relativement peu sécurisé et souhaite autoriser la transaction sur un appareil plus sécurisé. Par exemple, il pourrait autoriser un paiement ou une modification de ses renseignements personnels à la suite d’une notification push sur son téléphone mobile personnel.

​
Canaux de notification

Auth0 prend en charge les canaux de notification suivants avec CIBA :
  • Notifications push mobiles Auth0 Guardian : offertes avec tous les forfaits Enterprise. L’utilisateur reçoit une notification push sur son appareil mobile déjà inscrit pour s’authentifier ou confirmer les détails de la transaction. L’authentification et l’autorisation se font sur l’appareil d’authentification qui reçoit la notification push. Vous pouvez activer les notifications push mobiles avec CIBA au moyen de :
    • l’application Auth0 Guardian
    • une application personnalisée intégrée au SDK Auth0 Guardian
  • Notifications par courriel : offertes comme module complémentaire avec les forfaits payants. L’utilisateur reçoit un courriel à son adresse courriel vérifiée. Le courriel contient un lien, et l’authentification et l’autorisation se font dans le navigateur.
Par défaut, Auth0 utilise et recommande les notifications push Guardian pour les flux CIBA. Les notifications push Guardian sont plus sécuritaires que d’autres canaux, comme le courriel, qui peut être vulnérable aux attaques d’hameçonnage. Vous devez activer explicitement les notifications par courriel pour les flux CIBA.

​
Fonctionnement

Le diagramme suivant décrit le flux CIBA de bout en bout :
  1. L’application cliente ou l’appareil de consommation demande l’authentification ou l’autorisation de l’utilisateur.
  2. Le backend de l’application cliente envoie une requête POST au point de terminaison /bc-authorize.
  3. Auth0 reçoit la requête POST et envoie une notification à l’appareil d’authentification.
  4. L’appareil d’authentification récupère les détails d’autorisation auprès d’Auth0 et les présente à l’utilisateur final.
  5. L’utilisateur final examine la requête, y compris les détails d’autorisation contextuels qui s’y rapportent.
  6. L’utilisateur final fournit sa réponse sur l’appareil d’authentification, qui la transmet à Auth0.
  7. Le backend de l’application cliente interroge périodiquement le point de terminaison /token et reçoit les jetons appropriés une fois le flux CIBA terminé.
Comme le flux CIBA sert à l’authentification et à l’autorisation asynchrones ponctuelles des utilisateurs, CIBA ne crée ni ne stocke de grant contenant le consentement de l’utilisateur permettant à une application d’accéder aux ressources d’une API. Si l’utilisateur s’authentifie plus tard au moyen d’un flux d’authentification différent, et que ce flux demande les mêmes scopes que ceux auxquels l’utilisateur avait déjà consenti avec CIBA, Auth0 n’aura aucune trace de ce consentement. Il demandera donc à l’utilisateur de donner de nouveau son consentement.

​
Limites des entités

Le flux CIBA est soumis aux limites suivantes :
  • Jusqu’à 500 requêtes CIBA peuvent être créées par minute et par tenant.
  • Jusqu’à 5 000 requêtes CIBA en attente par tenant à un moment donné. Une requête CIBA en attente est une requête qui a été initiée, mais qui n’a pas encore reçu de réponse de l’utilisateur. Si une requête CIBA expire sans recevoir de réponse, elle peut continuer à être comptabilisée dans la limite de 5 000 pendant un maximum de 24 heures.

​
Premiers pas