Goodbye Passwords ? Intégrez les Passkeys avec Auth0 et Keycloak
Et si l’on se passait définitivement des mots de passe ? Telle est la promesse de WebAuthn et des passkeys (clés d’accès en français) qui ont vu le jour en 2019 lors de la publication d’une première spécification émise par l’alliance FIDO. Après cinq ans d’existence, qu’en est-il de leur utilisation au quotidien ? Si les grands noms du web ont commencé à mettre à disposition ce nouveau mode d’authentification, leur usage dans les applications reste tout de même en marge. Cette technologie est pourtant censée être accessible et facile d’implémentation. Nous allons vérifier au cours de cet article à quel point cela est vrai.
Notre choix d’implémentation se porte sur les deux serveurs d’authentification phares utilisés chez Octo, la solution Saas Auth0 et la solution open source Keycloak. Quand vient le moment de faire le choix idéal pour gérer les identités et les accès des utilisateurs, nous recommandons toujours de se tourner vers un partenaire avec une solution éprouvée plutôt que de partir sur une implémentation maison, et ces deux là ont fait leur preuve depuis longtemps !
Les passkeys en bref
L’utilisation des passkeys permet à un utilisateur de s'inscrire à un service puis de se connecter sans jamais avoir à produire de mot de passe. La passkey se compose d’une clef publique et d’une clef privée. La clef privée sera stockée de manière sécurisée sur un des appareils de l’utilisateur final, tandis que la clef publique sera enregistrée dans le serveur d’authentification du service. Lors de l’enregistrement d’un nouveau compte, il sera proposé à l’utilisateur de générer une passkey sur un appareil compatible de son choix (navigateur web, smartphone, trousseau iCloud…).
- Authenticator : appareil physique chargé de stocker en sécurité la clef privée et de vérifier l’identité biométrique de l’utilisateur en train de se connecter (ordinateur, mobile, clef physique, etc…)
- User : utilisateur de l’application
- Client : application, service auprès duquel l’utilisateur cherche à s’identifier
- Server : serveur d’authentification en charge de vérifier les identités des utilisateurs
Lors d’une tentative de connexion, une chaîne de caractère aléatoire (code challenge) est émise par le serveur d’authentification vers le client de l’utilisateur. Ce dernier est alors invité à se connecter à l’aide de sa clef enregistrée. La clef privée permet de signer le code challenge avant de le renvoyer au serveur d’authentification. La clef publique peut alors vérifier que le message a bien été signé par la clef privée dont elle est dérivée. Cette notion de signature est un procédé de cryptographie asymétrique. Aucune donnée sensible ne circule au cours de ces échanges.
> 💡 Remarque : Dans le cas ou l’Authentificator et le Client sont sur deux appareils distincts (par exemple, un ordinateur et un téléphone), il est nécessaire que le Bluetooth soit activé sur les deux terminaux pour garantir un échange sécurisé des données cryptographiques et vérifier la proximité des dispositifs. Cette norme n’est pas précisée dans la spec, cependant elle est fortement poussée par les constructeurs Google, Apple et Microsoft.
Si vous voulez en savoir plus sur les fondamentaux de cette technologie et ses avantages, nous vous invitons à vous référer à cet article du blog qui fait état du fonctionnement détaillé des passkeys.
Depuis la publication de l’article en 2019, la majorité des nouveaux smartphones sont compatibles WebAuthn.
Partie 1 : implémentation avec Auth0
Auth0 étant un service en ligne, il est nécessaire que vous possédiez un compte utilisateur afin de configurer un environnement d’authentification auprès d’eux. Pas besoin de compte payant pour cela ! Lien d’inscription à Auth0
Création de l’application
Lors de votre première connexion, Auth0 vous propose de créer une nouvelle application. Si vous possédiez déjà un compte, rendez-vous dans la gestion de vos applications et créez en une nouvelle. Nous nommerons notre nouvelle application “Octo-Passkey”. Pour le type d’application, nous choisissons Single Page Apps > Javascript.
Mise en place de l’authentification avec les passkeys
Lorsque vous utilisez un fournisseur de service pour gérer l’authentification à vos applications, le parcours de connexion et ses différentes vues sont généralement gérés par la solution choisie. C’est le cas dans Auth0.
Auth0 gère nativement l’authentification avec les passkeys. Il est néanmoins nécessaire de configurer plusieurs paramètres afin de proposer ce mode de connexion à vos utilisateurs. Nous allons nous intéresser aux éléments suivants :
- Paramétrage de la base de données
- Parcours d’enregistrement et d’authentification de Auth0
Auth0 met à votre disposition une base de données permettant de stocker les identifiants de vos utilisateurs. Nous devons la configurer afin qu’elle puisse dorénavant enregistrer les passkeys.
Sélectionner la connexion pré-existante et rendez-vous dans l’onglet Authentication Method
L’option “Passkey” est disponible. Si vous essayez de l’activer dès lors, une modale listant les pré-requis de cette méthode peut s’ouvrir selon la configuration de votre tenant Auth0.
Entrons dans la configuration en cliquant sur “Configure”. Nous sommes redirigés vers l’écran de gestion de notre politique des passkeys. Un menu déroulant nous propose un aperçu des pré-requis à leur activation ainsi que des liens vers chacun des éléments à activer / désactiver.
- Identifier First login flow : dans le parcours de connexion, il sera d’abord demandé à l’utilisateur son username, puis dans une seconde étape du formulaire le mot de passe. Cela permet au serveur d’authentification de vérifier si une passkey existe avant même de demander à l’utilisateur de renseigner un mot de passe.
- Custom Login Page : si la page de connexion est bien gérée par Auth0, une option peut la rendre entièrement customisable par nos soins. Cela n’est pas compatible avec les passkeys qui doivent respecter un ensemble de règles précises.
- Requires Username : ce paramètre demande à l’utilisateur de renseigner un nom en plus de son email lors de l’inscription.
- Use my own database : la gestion des passkeys et des infos utilisateurs doit être déléguée à Auth0 d’où le besoin de désactiver les bases de données custom à moins de partager les données avec le serveur d’authentification.
- New Universal Login Experience : flows de connexion proposés par Auth0, entièrement paramétrables dans les options de branding (textes, couleurs, aspects…).
Une fois l’ensemble des pré-requis complétés, nous pouvons désormais activer les passkeys comme méthode d’authentification. Nous pouvons dès lors tester l’enregistrement tel que le ferait un nouvel utilisateur de notre application.
⚠️ Assurez-vous que cette connexion de base de données est bien associée à l'application que vous venez de créer dans les paramètres de connexion de l’application.
Accès à l’environnement de test Auth0
Pour nos tests, nous utiliserons l’environnement intégré d’Auth0, accessible via le bouton "Try Connection" en haut à droite de la page de paramétrage de la connexion à la base de données. Cet environnement offre une simulation fidèle de l'expérience utilisateur finale, très pratique pour valider les flux d'authentification de nos utilisateurs avant un déploiement.
Enregistrement en tant que nouvel utilisateur
Sur l'écran d'accueil, sélectionnez "Sign Up" pour enregistrer un nouvel utilisateur. Après avoir saisi une adresse email, Auth0 propose de créer une passkey. Selon votre navigateur et la compatibilité de votre machine, vous serez invité à suivre un flow de création d’une passkey.
Option de Clé Supplémentaire
Lorsque l’on se connecte via un appareil sur lequel une passkey n’est pas déjà physiquement enregistrée, le protocole de connexion nous invite à en créer une nouvelle pour le device en cours d’utilisation.
La possibilité de créer et d'enregistrer plusieurs passkeys pour un même compte permet une flexibilité accrue, facilitant l'accès via différents dispositifs (ordinateurs, téléphones, clés physiques, etc.). Il est généralement recommandé de créer une passkey directement sur l’appareil via lequel on souhaite accéder au service cible pour simplifier les futurs processus de connexion. Créer une seconde passkey est également un moyen efficace de retrouver son compte au cas ou l’un des deux appareils devient inaccessible (oubli, perte, casse, vol, etc…)
Cette étape reste une option et n’est pas obligatoire si vous souhaitez garder un appareil unique comme option de connexion.
Intégration des passkeys dans Auth0 en bref
L'intégration des passkeys avec Auth0 se révèle être un processus intuitif et “clés en main”. Si vous utilisez déjà leurs services sur vos applications, il vous suffira de suivre les quelques étapes de configuration décrites pour mettre à disposition ce mode d’authentification auprès de vos utilisateurs.
Nous retiendrons notamment parmi ces avantages :
- Rapide à mettre en place et peu de setup technique
- Pas d’impact sur l’application web existante et ses règles métiers
- Peut être ajouté sur un système déjà en place et proposer un enrôlement progressif des utilisateurs
Nous notons tout de même quelques points de vigilances:
- Besoin de se conformer à un environnement Auth0 fort (désactivation des pages de login custom et adaptation à “Universal Login Experience”)
- Nécessité d’importer ses données utilisateurs dans Auth0 si l’on utilise une base de données personnalisée
Partie 2 : implémentation avec Keycloak
Keycloak est une solution open source de gestion des identités et des accès (IAM) développée par Red Hat. Il permet de gérer l'authentification et l'autorisation des utilisateurs pour les applications web et les services. Keycloak propose les passkeys depuis la version 23, c’est-à-dire depuis novembre 2023.
Nous choisissons pour cet exemple de faire tourner Keycloak sur un container Docker en local en s’inspirant de ce tutoriel.
Nous partirons donc d’un Keycloak vierge auquel nous ajouterons une application avec authentification par passkey. Si vous souhaitez suivre le déroulé de cet article, vous pouvez utiliser cette image de Keycloak qui contient seulement un realm master par défaut.
docker run -p 8080:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:25.0.0 start-dev
Keycloak met en place une interface web permettant de tester la configuration de son serveur d’authentification : c’est ce que nous allons utiliser pour tester l’authentification par passkey.
Création de l’application
Après lancement du container Docker, nous nous connectons à l’interface d’administration (sur le port 8080).
Nous commençons par créer le realm dans lequel sera enregistrée notre application :
On peut ensuite enregistrer notre application dans l’onglet Clients. Nous laissons tous les réglages par défaut mis à part les champs :
- “Valid redirect URIs”: https://www.keycloak.org/app/*
- “Web origins” : https://www.keycloak.org
“Valid redirect URIs” désigne les URLs de redirection autorisées après s’être authentifié dans la mire d’authentification Keycloak. “Web Origins” désigne la liste des origines CORS autorisées.
Renseigner ces deux valeurs nous permettra de tester notre serveur d’authentification sur la Single Page Application hébergée par Keycloak. En production, nous aurions mis l'URL de notre SPA.
Activation de WebAuthn et des Passkeys
Pour permettre l’utilisation des passkeys sur notre realm Keycloak, nous devons mettre en place :
- le flow d’enregistrement d’une nouvelle passkey lors de l’inscription
- le flow d’authentification avec passkey
Enregistrement d’une passkey à l‘inscription
Vérifiez dans l’onglet Authentication > Required Actions que l’action “WebAuthn Register” est bien activée.
Ensuite, pour obliger les nouveaux inscrits à enregistrer une passkey, nous passons “Webauthn Register Passwordless” à “Set as default action”
Nous voulons maintenant donner la possibilité aux utilisateurs d’enregistrer une nouvelle passkey lors de leur première connexion.
On active tout d’abord l’option “User Registration” dans Realm settings > Login pour pouvoir s’inscrire à la première connexion :
Comme nous voulons faire du passwordless pur et dur, nous désactivons aussi l’obligation de spécifier un mot de passe à l’inscription (en passant “Password Validation” à “Disabled” dans le flow par défaut Registration) :
Authentification avec passkey
Nous allons à présent ajouter un nouveau flow d’authentification web qui utilise les passkeys. Dans Authentication > Flows, nous dupliquons le flow browser par défaut pour créer notre nouveau flow browser-passkey :
Nous adaptons le flow pour utiliser le “WebAuthn Passwordless Authenticator” :
On peut à présent désigner ce nouveau flow comme flow par défaut pour les navigateurs :
Et c'est tout pour ce qui est des réglages !
Test du flow d’authentification par passkey
Il ne nous reste à présent plus qu’à tester. La Single-Page Application mise à disposition par Keycloak est disponible à l’adresse https://www.keycloak.org/app/ .
Il suffit d’y préciser l’url du serveur d’authentification, le nom du realm et le nom du client :
Nous arrivons ensuite sur la mire d’authentification de Keycloak. Elle devrait ressembler à ça si vous avez suivi jusqu’ici :
Comme il s’agit de notre première connexion, nous remplissons quelques informations (tout cela est configurable dans Keycloak mais nous gardons un flow à peu près standard pour ne pas s’égarer) :
Nous sommes ensuite redirigés vers la mire d’enregistrement de notre passkey : 
En cliquant sur Register, en fonction de votre navigateur, vous aurez la possibilité d’enregistrer une passkey en local ou sur un autre device.
A la fin de cette étape, nous sommes finalement authentifiés et redirigés vers notre app. Ça y est, notre compte et notre passkey sont créés !
On peut maintenant essayer de se déconnecter puis se reconnecter pour tester le flow d’authentification. Votre navigateur devrait automatiquement vous suggérer la passkey que vous venez de créer. Sur Chrome, ça ressemble à ça :
Plus qu’à s’authentifier avec la méthode choisie à l’enregistrement, et voilà : nous sommes de nouveau connectés.
Nous avons donc pu nous créer un compte sur un serveur Keycloak uniquement avec une passkey ! Comme nous le verrons après, en production, il est plus prudent de permettre un flow d’authentification alternatif en cas d’oubli / de perte de l’appareil sur lequel est stocké la passkey.
Intégration des passkeys dans Keycloak en bref
L'intégration des passkeys avec Keycloak demande un peu plus de configuration que sur Auth0 mais reste relativement simple (pas de plug in particulier à installer).
Le principal point de vigilance est que les passkeys ne sont disponibles que depuis la version 23 de Keycloak. Donc si vous utilisez déjà Keycloak en production dans une version antérieure il faudra faire la migration.
Partie 3 : considérations autour des passkeys
Comment ça marche si je n’ai pas mon appareil avec ma passkey enregistrée sur moi?
Si vous n’avez pas d’autre moyen d’authentification, alors vous êtes bloqué! Il y a plusieurs moyens de mitiger ce risque.
Certains systèmes d’exploitation permettent de partager les passkeys entre appareils:
- MacOS/iOS offre la possibilité de stocker sa passkey sur iCloud avec une iCloud keychain, ce qui permet de contourner ce problème si vous avez un autre appareil connecté à iCloud disponible
- Sur Android, les passkeys sont partagées entre tous vos devices Android via Google Password Manager
- Windows propose de stocker les passkeys avec Windows Hello mais uniquement en local, donc pas encore de partage entre appareils
Il est donc nécessaire de prévoir une solution de récupération d’accès au compte ou un flow de connexion alternatif sur votre application pour éviter qu’un utilisateur soit bloqué pour cette raison.
Et si mes appareils ne supportent pas les passkeys?
Ce cas de figure devrait être de plus en plus rare à mesure que le temps passe car la spécification FIDO et les passkeys notamment sont poussées par les acteurs majeurs de la tech ( Google, Microsoft, Apple, …).
Cependant cela peut encore arriver aujourd’hui, et c’est une raison de plus pour garder un flow d’authentification plus traditionnel en plus des passkeys sur vos applications.
Comment ça s'implémente dans mon application web ou mobile ?
Tant que le serveur d’authentification est compatible avec la spécification WebAuthn, les passkeys s’implémentent de la même manière qu’un flow d’authentification OAuth + OIDC classique. La grande majorité du flow sera gérée par le serveur d’authentification. En fonction de la solution d'authentification utilisée, il y aura peut-être besoin de développer quelques fonctionnalités complémentaires propres à la gestion des passkeys (suppression des passkeys compromises par exemple).
Pour découvrir tous les flows d’authentification disponibles, nous vous invitons à vous référer à l’article Sécuriser son API
Conclusion
Les passkeys sont un mécanisme d’authentification puissant qui permet à la fois de sécuriser et de simplifier l’expérience utilisateur d’inscription et d’authentification dans une application.
Il n’y a pas encore de standard sur la récupération d’un compte dans le cas où la passkey n’est plus accessible. C’est un point à prendre en compte lors de leur implémentation.
Parmi les considérations d’implémentation nous noterons également :
- Le besoin de mettre en place des fonctionnalités de gestion des passkeys (suppression, expiration)
- Le niveau de sécurité attendu, WebAuthn ne peut pas imposer de critère spécifique sur le niveau de verrouillage du moyen d’authentification (code pin, biométrie, schéma)
Les passkeys deviennent la solution d’authentification de référence. Elles sont toujours plus poussées par les géants du web et sont en cours d’adoption par la plupart des solutions d’IAM comme Auth0 et Keycloak qui facilitent leur intégration dans vos applications, nouvelles ou existantes.
En tant que développeur d’applications, vous avez donc tout intérêt à les proposer à vos utilisateurs !
Remerciements
Merci à Arnaud Doucerain, Alain Faure, Mathieu Le Morvan, Adrien Graux, Daniel Sala et Loic Lefloch pour leur relecture attentive.