Améliorer l’expérience client avec le CIBA

Aujourd’hui plus que jamais, les consommateurs exigent une expérience exceptionnelle lorsqu’ils interagissent avec votre entreprise, en particulier lorsque ces échanges ont lieu dans l’espace numérique. Ces attentes ne cessent d’augmenter au fur et à mesure que les consommateurs réalisent des transactions dans le monde de l’Open Banking. Qu’ils s’agisse des activités bancaires réalisées sur le téléphone portable ou des achats réalisés en ligne jusqu’à l’utilisation d’agrégateurs de données financières tiers, vos clients veulent contrôler la manière et le moment où ils partagent leurs données financières personnelles. Ils veulent contrôler la diffusion de leurs données, les destinataires et gérer quels tiers ont accès à leurs données tout au long de leur relation avec ceux-ci.

Pour les entreprises qui souhaitent améliorer l’expérience de l’utilisateur final pendant les phases d’authentification et d’autorisation, une nouvelle caractéristique technique a été conçue pour vous aider à réaliser précisément cela. CIBA, l’authentification par voie de retour initiée par le client est une extension de OpenID Connect, le standard d’identité fédéré et ouvert pour la single sign-on (SSO) , tpermettant un accès fluide au SaaS, et aux applications mobiles, cloud et de l’entreprise. CIBA est particulièrement importante pour les entreprises fournissant des services financiers et pour les sociétés de technologie financières tout en tenant la promesse d’innover dans de multiples secteurs ; elle prend actuellement de l’ampleur partout dans le monde et Ping Identity soutient désormais cette importante extension.

CIBA is a new specification written in part by Ping’s own Brian Campbell, developed out of the groupe de travail MODRNA de la Fondation OpenID. À l’instar d’OpenID Connect, CIBA est un flux d’authentification gouvernant la manière d’authentifier les clients et de leur autoriser les accès. Mais contrairement à OpenID Connect, il y a avec CIBA une communication directe entre la partie de confiance et le fournisseur d’OpenID sans redirection par le navigateur de l’utilisateur. Dit autrement, cette extension définit un nouveau type d’autorisation OAuth lorsque le consentement de l’utilisateur peut être demandé par un flux hors-bande.

CIBA améliore l’expérience de l’utilisateur en fluidifiant la manière dont les utilisateurs donnent leur consentement numérique. Par exemple, lorsqu’un client réalise un achat en ligne auprès d’un vendeur, la procédure n’exige pas une redirection du navigateur vers une institution afin qu’elle autorise l’achat. Au lieu de cela, pour valider l’autorisation, l’utilisateur peut recevoir une notification en push envoyée vers l’appli mobile native de l’institution financière sur le téléphone de l’utilisateur, ce qui permet au client d’éviter les redirections déroutantes sur les navigateurs du web.

Voici un exemple de flux depuis la perspective du client, illustré par un achat sur le site web d’une société imaginaire :

1. Un consommateur visite le site d’un vendeur et lance un achat.

2. Le consommateur choisit de payer son achat par le biais de sa banque. Mais au lieu d’être redirigé vers le site web de sa banque, l’utilisateur reste sur le site du vendeur.

3. Quelques instants plus tard, l’utilisateur voit apparaître sur son smartphone une notification sur l’appli native de sa banque (ce qui est possible grâce à un outil tel que PingID SDK, qui permet aux développeurs d’installer des services d’identité sécurisés sur leurs propres applications).

4. L’utilisateur ouvre l’application, s’authentifie si besoin, et découvre les détails de l’achat qu’il souhaite réaliser.

5. L’utilisateur approuve l’achat, s’il le souhaite, par le biais de l’appli de la banque. Une étape biométrique (par ex. TouchID, FaceID, etc.) peut être mise en place

6. L’utilisateur voit le retour sur le navigateur web confirmant que l’achat a été réalisé, le tout sans avoir été redirigé en dehors du site web du vendeur.

PingFederate, l’autorité d’authentification et le serveur SSO fédéré de Ping, prend désormais en charge ces configurations dans PingFederate version 9.3. Dans les coulisses, voici à quoi ressemble réellement le flux découplé :

1. Le Client fait une demande d’authentification par voie de retour sous la forme d’une requête « HTTP POST » au terminal d’authentification par voie de retour (un nouveau terminal défini par CIBA) pour demander l’authentification de l’utilisateur final.
2. Après avoir reçu la requête, le fournisseur d’OpenID (OP) répond immédiatement avec un identifiant unique qui identifie cette authentification tout en essayant d’authentifier l’utilisateur dans le contexte. (Ce processus d’authentification peut avoir lieu sur un smartphone, qui transmet le résultat au serveur d’autorisation.)
3. Le client reçoit alors le jeton d’identification, le jeton d’accès et éventuellement un jeton de rafraichissement. PingFederate prend naturellement en charge tant le mode Poll que le mode Ping ; ce choix doit être réalisé par le client lorsqu’il s’enregistre.
   • Mode Poll : en cas de configuration en mode Poll, le client interrogera le terminal du jeton pour obtenir une réponse avec les jetons.
   • Mode Ping : en cas de configuration en mode Ping, l’OP enverra une demande à une URI de rappel enregistrée par le client et l’identifiant unique sera renvoyé par le terminal d’authentification par voie de retour. Dès qu’il recevra la notification, le client fera une requête au terminal du jeton pour obtenir les jetons.

Bien que nous ne détaillons pas ici ce qui se passe au niveau de PingFederate/OP pour interagir avec l’utilisateur, car cela est spécifique à chaque installation, nous supposons que l’interaction la plus courante avec l’utilisateur final sera réalisée avec une notification en push sur l’appli mobile native du client.

En plus d’avoir l’avantage susmentionné d’améliorer l’expérience de votre utilisateur final en fournissant aux utilisateurs la possibilité de donner leur consentement par le biais d’un flux hors bande, CIBA a des répercussions importantes dans le domaine de l’Open Banking. Les clients de l’Open Banking peuvent garder leur avance sur les standards en pleine évolution en déployant leur solution de CIBA, qui standardise la manière dont les utilisateurs autorisent une transaction bancaire sur un terminal secondaire. En Europe, CIBA permet aux banques de mettre en place des flux d’authentification dissociés définis par la DSP2 et l’Open Banking britannique.

Et désormais, conformément au Consumer Data Right (CDR) de l’Open Banking en Australie, toutes les institutions financières qui détiennent des comptes clients doivent fournir des API ouvertes qui permettent de partager en toute sécurité les données des comptes avec des récepteurs de données tiers. Les institutions de services financiers australiens sont sur le point d’adopter une technologie qui leur permet d’exposer et de protéger des API de données des comptes dans un cadre sécurisé qui met en priorité les droits des consommateurs sur leurs données, sur le respect de leur vie privée et sur le consentement informé. Tandis que certains cadres actuels s’appuient sur des standards qui existent depuis longtemps, tels que OAuth 2.0 et OpenID Connect, CIBA est l’un des flux standards d’échange de données recommandée pour une future incorporation dans les caractéristiques par le Comité consultatif. (Elle a été retirée de la dernière version de v1.0, qui est toujours en cours de vérification et n’a pas encore été finalisée.)

Chez Ping Identity, nous sommes directement impliqués dans le développement de l’Open Banking dans le monde. Nous avons aidé à rédiger les standards (Mark Perry, Directeur technique de Ping pour la zone Asie-Pacifique, est le seul représentant commercial du comité consultatif du CDR australien, et Rob Otto, Directeur technique de Ping pour la zone EMEA, travaille étroitement avec l’Open Banking Implementation Entity et avec le groupe OICD FAPI) et nous comptons rester en ligne avec le secteur tout en gardant une longueur d’avance. Pour en savoir plus sur ce que Ping fait pour aider les institutions financières à respecter les réglementations concernant les principales API, rendez-vous sur notre page consacrée au Consumer Data Right australien.