Simplifier les paiements Open Banking en dissociant l’authentification

En juillet dernier, mon collègue Mark Perry rédigeait un article de blog pour décrire comment une nouvelle caractéristique d’OpenID Connect appelée Client Initiated Backchannel Authentication (CIBA), l'authentification par voie de retour initiée par le client, pouvait être utilisée pour améliorer l’expérience client dans de nombreuses interactions avec une organisation. Mark parlait d’utiliser les fonctionnalités de dissociation de l’authentification du CIBA pour rationaliser le processus d’authentification des clients et recueillir leur consentement numérique pour les transactions, le tout sans redirections sur le navigateur, que de nombreux clients trouvent pénibles.

J’aimerais utiliser des passages d'articles de blog rédigés par Mark et les étoffer à l’aide plusieurs exemples de cas d’usage concrets, tous étant relatifs aux paiements numériques par l’Open Banking. J’ai utilisé les fonctionnalités de PingFederate (qui est entièrement compatible avec le CIBA, version 9.3), et le SDK de PingID pour présenter quelques alternatives que les banques et d’autres prestataires pourraient utiliser pour proposer à leurs clients et partenaires commerciaux de la flexibilité et du choix au niveau du processus d’approbation des paiements.

L’Open Banking est la mise en œuvre de la législation européenne DSP2 ; son fonctionnement et sa sécurité s’appuient sur une structure technique fondée sur le standard OpenID Connect. La première version de l’Open Banking Security Profile s’appuyait simplement sur un modèle de redirection sur le navigateur, recommandé par l’OICD FAPI. Dans ce modèle, un client était redirigé en toute sécurité vers le site web d’authentification de sa banque pour prouver son identité et approuver les transactions de paiement, avant d’être ensuite redirigé vers le site marchand en vue d’obtenir la confirmation de sa commande. Si on considère généralement que cette approche offre le meilleur niveau de sécurité possible, les retours que les clients réels en ont donné au fil du temps a montré qu’elle présente plusieurs problèmes d’ergonomie.

Les clients se sont plaints du nombre d’étapes qui sont généralement requises pour réaliser un paiement et ont, dans certains cas, décidé d’abandonner toute la transaction en raison du nombre inattendu (et souvent déroutant) de redirections ayant lieu. Ce modèle a rencontré encore moins de succès chez les marchands, qui déplorent la perte de contrôle sur l’interface de l’utilisateur et l’expérience médiocre entraînée par les redirections. Ces problèmes sont exacerbés lorsque le client utilise un appareil mobile.

En tenant compte de ces retours, le groupe chargé des standards de l’Open Banking, en étroite collaboration avec l’OpenID Foundation, a décrit plusieurs approches alternatives que les banques et les prestataires peuvent mettre en place en utilisant l’authentification dissociée et le CIBA pour résoudre ces difficultés. 

La partie 2.3 des Open Banking Customer Experience Guidelines (Conseils sur l’expérience client avec l’Open Banking) mises à jour, décrit en détail ces flux dissociés, je vais cependant essayer de résumer ici les principales options à l’aide de démonstrations simples. 

L’un des problèmes les plus difficiles à résoudre lorsque l’on utilise le CIBA pour dissocier l’authentification est d’identifier le bon utilisateur. Dans un modèle de redirection, le prestataire n’a même pas besoin de connaître l’identité de l’utilisateur à la banque ; cette étape d’identification est prise en charge directement par le site de la banque après la première redirection. Dans un flux dissocié, cela est impossible, car l’utilisateur n’est jamais redirigé. Au lieu de cela, le prestataire doit faire quelque chose pour prouver à la banque l’identité de l’acheteur. Étant donné que sa vie privée devrait être aussi protégée que possible, le fait de lui demander de saisir simplement son identifiant bancaire ne constitue peut-être pas la meilleure approche ! 

Les trois scénarios ci-dessous montrent qu’il existe des options alternatives. Dans chaque cas, je commencerai par une courte vidéo présentant le parcours que notre acheteur mystère (à l’instar de n’importe quel titulaire d’un compte chez AnyBank), Angela, réalisera en achetant un appareil sportif sur le site web Limitless Ambition. Je détaillerai ensuite chaque flux, en essayant de ne pas employer de termes trop techniques.

Option 1 : régler avec un identifiant utilisateur à usage unique

Nous commençons par un scénario dans lequel l’acheteuse, Angela, n’a jamais utilisé son compte AnyBank pour faire un achat sur le site Limitless Ambition. Dans ce cas, elle utilise un identifiant utilisateur à usage unique généré spécialement pour lancer la procédure. Cet identifiant utilisateur à usage unique est généré par son appli mobile AnyBank, en utilisant un processus sécurisé entre l’appli et le back-end d’AnyBank. L’identifiant utilisateur à usage unique est associé au compte d’Angela et ne peut être utilisé qu’une seule fois ; c’est à l’infrastructure de back-end de la banque d’associer cet identifiant à l’identité réelle d’Angela.

Angela peut communiquer en toute sécurité cet identifiant directement à Limitless Ambition, et lorsque le site web lance le flux de dissociation de l’authentification avec CIBA pour approuver le paiement, l’identifiant utilisateur à usage unique est envoyé au Fournisseur OpenID d’AnyBank en qualité d’indice de connexion. AnyBank utilise PingFederate, qui lui permet de déréférencer l’identifiant utilisateur à usage unique pour déterminer le nom de l’utilisateur réel par le biais d’un simple appel API, avant d’utiliser le SDK PingID pour envoyer le message d’approbation du paiement vers le bon téléphone portable.

Ce schéma n’offre pas nécessairement la meilleure expérience utilisateur sur un site web, car il est nécessaire de générer puis de saisir un identifiant utilisateur à usage unique. Si Angela réalisait un paiement sur l’appareil d’un point de vente, par exemple dans un kiosque en magasin, cela pourrait toutefois être bien plus utile. Dans ce cas, l’appli AnyBank afficherait l’identifiant utilisateur à usage unique sous la forme d’un code QR, que le kiosque pourrait scanner, au lieu de devoir taper quelque chose.

Option 2: régler avec un code QR

Une alternative à l’approche ci-dessus commence avec la même condition préalable : Angela n’a encore jamais utilisé son compte AnyBank pour faire un achat sur le site Limitless Ambition. Dans ce cas, toutefois, Limitless Ambition générera une référence unique pour la transaction de paiement et utilisera cette valeur à titre d'indice de connexion envoyé à AnyBank dans le cadre de l’appel CIBA. (Ceux qui connaissent les flux de paiement de l’Open Banking réaliseront certainement que le marchand pourrait utiliser l’identifiant d'intention que la banque envoie après le paiement en qualité d’identifiant unique et prêt à l’emploi pour cette utilisation).

Dans ce cas, Limitless Ambition codifie la référence unique sous la forme d’un code QR pouvant être scanné et l’affiche sur sa page web. Angela doit scanner ce code depuis l’appli mobile AnyBank pour approuver le paiement et terminer sa commande. 

Ce qui rend ce flux un peu inhabituel est le fait que le marchand (Limitless Ambition) ne peut pas fournir d’indice de connexion à AnyBank pour identifier l’utilisateur. L’indice de connexion est simplement une référence connue des deux parties, c’est à AnyBank de « déterminer » de quel utilisateur il s’agit. En scannant le code QR avec son appli mobile, Angela peut effectuer la transaction. Et, étant donné que son appli mobile connaît son identité et détient aussi la référence unique, elle peut passer un appel sécurisé au back-end d’AnyBank pour associer son identité à la référence de cette transaction, obtenir des informations supplémentaires sur le paiement et avoir son consentement ainsi que son approbation avant qu’AnyBank n’émette les jetons appropriés au marchand. 

Option 3 : utiliser un jeton d’identité déjà enregistré

La troisième option est la plus fluide de toutes pour l’acheteur, mais elle débute par une hypothèse différente. Dans ce cas, Angela a déjà utilisé son compte AnyBank pour faire un achat sur le site Limitless Ambition, probablement en utilisant les flux ci-dessus, ou bien un processus antérieur basé sur les redirections. Nous pouvons supposer que Limitless Ambition a conservé le jeton d’identité reçu par AnyBank pendant ce processus et l’a stocké en toute sécurité dans son propre annuaire de back-end, en l’associant au compte Limitless Ambition d’Angela.

Désormais, chaque fois qu’Angela souhaitera faire un achat sur le site, Limitless Ambition pourra lancer directement une authentification dissociée, en transmettant ce jeton enregistré à titre d'indice de jeton d’identification, comme décrit dans les caractéristiques CIBA.

Le fournisseur OpenID d'AnyBank, optimisé par PingFederate, est capable d’extraire suffisamment d’informations à partir de cet ancien jeton d’identité et de déterminer qu’Angela est l’utilisateur, même lorsque le jeton d’identité ne contient pas réellement son nom d’utilisateur. PingFederate utilise alors le SDK PingID pour envoyer un message détaillé d’approbation de la transaction à l’appareil mobile d’Angela, sans qu’elle ait besoin de faire quoi que ce soit d’autre.

Vous pouvez noter que dans tous ces cas, Limitless Ambition garde le contrôle total de toute l’expérience utilisateur sans devoir à aucun moment rediriger le navigateur d’Angela vers d’autres pages extérieures à son site Web. 

Grâce au travail que nous réalisons avec l’OpenID Foundation et à notre solution complète pour l’authentification et le consentement des clients, Ping Identity est le fournisseur parfait de solutions pour les entreprises souhaitant améliorer l’expérience client en utilisant l’authentification dissociée et le CIBA. Tandis que les exemples ci-dessus portent sur les banques et les paiements, nous débordons d’idées sur la manière dont le CIBA pourrait également apporter une valeur immense à nos clients dans d’autres secteurs. Contactez-nous et nous vous montrerons comment utiliser le CIBA avec Ping Identity.