De nos jours, la gestion des accès et la notion de sécurité des APIs sont indissociables des protocoles de fédérations OAuth2 et OpenID Connect. Ces deux protocoles couvrent nativement un grand nombre de cas d’usage, mais évoluent régulièrement et sont accompagnés de compléments pour adresser des sujets plus novateurs.
Notamment, avec l’explosion des IoT et les réglementations tels que la DSP2, le besoin de déclencher des authentifications décorrélées du medium d’accès de l’utilisateur se fait de plus en plus présent : en effet, ce dernier ne dispose peut-être pas des interfaces nécessaires, ou peut ne pas être reconnu comme un support suffisamment sécurisé.
La cinématique additionnelle CIBA, Client Initiated Backchannel Authentication Flow a pour but de définir les échanges et les appels permettant de déclencher des tels authentifications. Ce premier article a pour but de décrire brièvement le fonctionnement haut niveau de cette cinématique, et de présenter les apports et les cas d’usage supplémentaire qu’il peut couvrir.
C’est quoi CIBA ?
CIBA signifie Client Initiated Backchannel Authentication. Il s’agit d’un nouveau flux d’authentification et d’autorisation du standard OpenID Connect définit par la fondation Open ID.
Le flux CIBA est le premier flux d’OpenID qualifié de « découplé » car il introduit la notion de Consumption Device (CD) et d’Authentication Device (AD). Le CD est l’appareil sur lequel l’accès à un service (Relying Party, RP) est demandé tandis que l’AD est l’appareil sur lequel l’utilisateur s’authentifie auprès de l’OpenID Provider (OP) et autorise l’accès qui est demandé sur le CD, en donnant son consentement.
Contrairement aux autres flux du standard OIDC, CIBA considère donc que l’utilisateur peut s’authentifier sur un appareil différent de celui sur lequel il veut accéder au service. Par exemple, un utilisateur cherche à accéder à son compte en banque depuis son ordinateur et s’authentifie pour autoriser l’accès depuis son smartphone.
Quels apports ?
Le flux CIBA présente plusieurs intérêts significatifs pour l’authentification des utilisateurs.
Les flux d’authentification OIDC aujourd’hui sont conçus autour de la notion de redirections web entre le service accédé (Relying Party) et le fournisseur d’identité. Ces redirections peuvent se montrer inconfortables et perturbantes pour l’utilisateur qui voit son navigateur ou son application passer d’un site à un autre sans forcément comprendre ce comportement. Avec CIBA, l’appareil que l’utilisateur utilise pour accéder à un service reste sur la page du service demandé en attendant que l’authentification soit réalisée sur l’AD. Cette disparition des redirections améliore également l’acceptation des Relying Party qui ne perdent plus le contrôle et la visibilité des actions de l’utilisateur lorsque ce-dernier doit s’authentifier auprès de l’OP.
Bénéfice par population
L’authentification multi-facteur (MFA) est de plus en plus répandue et recommandée pour accéder à des services sur Internet. Les SMS, les soft-token ou encore les Out-Of-Band push notification sont divers exemples de facteurs d’authentification additionnels, utilisés aujourd’hui en complément d’un mot de passe. Avec CIBA, la présence de ce facteur fait naturellement partie de l’authentification puisque celle-ci s’effectue sur un appareil enregistré comme AD. En demandant à l’utilisateur de s’authentifier sur l’AD avec un mot de passe, un code PIN, un facteur biométrique, … on permet de centraliser les actions d’authentification sur un seul et même appareil tout en permettant de faire du MFA.
Exemples de cas d’usage
Le call center
Lorsqu’un client appelle aujourd’hui un centre d’aide ou de services, l’opérateur vérifie le plus souvent l’identité du client avec diverses questions personnelles (date et lieu de naissance, numéro de sécurité sociale) ou bien à l’aide des questions de sécurité. Cette méthode d’authentification est particulièrement vulnérable à des attaques telles que l’ingénierie sociale.
Grâce à CIBA, il est possible pour l’opérateur de déclencher une demande d’authentification de l’appelant sur son Authentication Device et ainsi s’assurer de façon plus sécurisée de l’identité du client.
Les assistants virtuels
La DSP2 impose aux organismes bancaires de s’assurer de l’identité de la personne effectuant une opération au-dessus de certain montant, ce qui passe obligatoirement par une phase d’authentification (2 facteurs) lors d’un transfert par exemple. Néanmoins, les IoT tels que les assistants vocaux ne disposent pas d’interface permettant à l’utilisateur de saisir leurs identifiants, et forcer le client à valider une demande de transfert sur un portail web via son smartphone ou son pc n’est pas l’expérience utilisateur idéale. CIBA permet de s’affranchir de cette contrainte, car la banque du client est alors en capacité d’envoyer une demande d’authentification directement sur le bon terminal (AD), limitant l’impression de rupture de parcours pour le client.
Conclusion
La cinématique d’authentification CIBA comble de vraies faiblesses du protocole OpenID Connect, tant au niveau de la couverture fonctionnelle que de l’expérience utilisateur. Sa mise en œuvre dans le monde réel devrait se faire rapidement, et de nombreux acteurs du marché regardent déjà comment l’implémenter.
