Flux d’authentification par canal d’appui initié par le client

Découvrez comment fonctionne le 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.

Le flux d’authentification par voie de retour initié par le client (CIBA) est une norme OpenID Foundation pour un flux d’authentification découplé. Il permet aux développeurs de créer des flux d’authentification où l’utilisateur ne se connecte pas directement sur l’appareil qui reçoit l’ID ou les jetons d’accès, ou sur l’appareil de consommation, mais sur un appareil d’authentification distinct.

​

Cas d’utilisation

Utiliser le flux CIBA pour les cas d’utilisation suivants :

• Un utilisateur a téléphoné à un centre d’appels et l’agent qui traite l’appel souhaite accéder aux renseignements personnels de l’appelant sur son ordinateur. L’appelant peut consentir à cela en approuvant une notification poussée sur son téléphone.
• Un utilisateur souhaite accéder à un appareil dont les capacités de saisie sont limitées, comme un vélo que vous pouvez louer dans une ville ou un kiosque dans un magasin.
• Un utilisateur initie une transaction sensible sur un appareil relativement peu sécurisé et souhaite autoriser la transaction sur un appareil plus sécurisé. Par exemple, il peut autoriser une transaction sensible à la suite d’une notification poussée sur un téléphone mobile personnel.

​

Comment ça fonctionne?

Le flux CIBA ne s’appuie pas sur une application client qui redirige l’utilisateur via le navigateur pour effectuer le processus de connexion/authentification. Au lieu de cela, l’application client appelle directement le fournisseur OpenID via une demande par voie de retour pour initier le flux d’authentification.

Le flux CIBA ne crée ni ne met à jour une autorisation. Par conséquent, si l’application client demande une permission en question via le flux CIBA, elle ne sera pas stockée comme autorisation si l’utilisateur y consent. Cela signifie que si configuré, un flux d’authentification différent (type d’autorisation) demandant la même permission(s) doit demander à l’utilisateur de nouveau le consentement OAuth.

Étant donné que le flux CIBA n’a pas de sessions, c.-à-d. témoins du navigateur, l’utilisateur n’a pas besoin d’être authentifié avant un défi CIBA. S’ils ont déjà été authentifiés avant un défi CIBA, leur session existante n’est pas affectée.

Le diagramme suivant décrit le flux CIBA :

1. L’application client ou l’appareil de consommation demande une authentification utilisateur.
2. Le système dorsal de l’application client envoie une demande POST au point de terminaison /bc-authorize.
3. Auth0 reçoit la demande POST et envoie une notification poussée à l’appareil d’authentification.
4. L’appareil d’authentification récupère les données de consentement de Auth0 et les présente à l’utilisateur final.
5. L’utilisateur final fournit sa réponse sur l’appareil d’authentification qui soumet la réponse de l’utilisateur à Auth0.
6. Le système dorsal de l’application client interroge le point de terminaison /token et reçoit les jetons appropriés à la fin du flux CIBA.

Lire…	Pour apprendre…
Configurer une authentification Back-channel initiée par le client	Comment configurer le type d’autorisation CIBA pour votre application.
Authentification des utilisateurs avec CIBA	Comment authentifier des utilisateurs avec le flux CIBA, étape par étape.