Explication technique de la Conditional UI WebAuthn

Avec l'adoption rapide des clés d'accès (et du protocole WebAuthn sous-jacent), l'authentification est devenue plus sécurisée et conviviale pour de nombreux utilisateurs. L'une des avancées marquantes des clés d'accès a été l'intégration de la Conditional UI, souvent appelée « remplissage automatique des clés d'accès » ou Conditional Mediation (dans la suite, nous conserverons le terme Conditional UI).

Malgré son introduction récente et son adoption continue par les navigateurs, il y a un manque notable dans la documentation technique et les conseils d'implémentation pour la Conditional UI. Cet article vise à combler ce vide en expliquant ce qu'est la Conditional UI, comment elle fonctionne et comment résoudre les défis courants lors de son implémentation.

Aide-mémoire Passkeys. Conseils pratiques, modèles de déploiement et KPIs pour les programmes passkeys.

Obtenir l'aide-mémoire

La Conditional UI représente un nouveau mode pour les processus de connexion par clés d'accès / WebAuthn. Elle affiche de manière sélective les clés d'accès dans une interface utilisateur (UI) uniquement lorsqu'un utilisateur possède un identifiant découvrable (clé résidente), qui est un type de clé d'accès, enregistré auprès de la partie utilisatrice (le service en ligne) et stocké dans l'authentificateur de son appareil (par ex. ordinateur portable, smartphone). Les clés d'accès sont affichées dans un menu déroulant de sélection mélangé aux mots de passe remplis automatiquement, offrant une transition fluide entre les systèmes de mots de passe traditionnels et l'authentification avancée par clés d'accès, car les utilisateurs voient les deux dans le même contexte. Cette approche intelligente garantit que les utilisateurs ne sont pas submergés d'options inutiles et peuvent naviguer dans le processus de connexion plus fluidement.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

Découvrez comment VicRoads a déployé les passkeys pour plus de 5M d'utilisateurs, aux côtés de son IDP existant.

Lire l'étude de cas

La base de la Conditional UI repose sur trois piliers principaux :

1. Respect de la vie privée des utilisateurs : Garantir la vie privée des utilisateurs en empêchant la divulgation des identifiants disponibles ou le manque de consentement de l'utilisateur pour révéler ces identifiants.
2. Excellente expérience utilisateur même si aucune clé d'accès n'existe : Permettre aux parties utilisatrices d'implémenter WebAuthn de manière opportuniste, en s'assurant que l'expérience utilisateur reste bonne même si les clés d'accès ne sont pas disponibles.
3. Transition fluide des mots de passe vers les clés d'accès : Combiner les clés d'accès avec l'authentification par mot de passe pour adoucir la transition vers les méthodes d'authentification sans mot de passe, en capitalisant sur les paradigmes UX familiers des utilisateurs.

• Authentification simplifiée : Le processus est plus rationalisé et efficace, supprimant les complexités souvent associées à de multiples méthodes d'authentification.
• Réduction des erreurs utilisateur : En ne présentant que les options pertinentes, les utilisateurs sont moins susceptibles de faire des erreurs lors du processus d'authentification.
• Amélioration de la satisfaction utilisateur : La suppression des étapes inutiles signifie que les utilisateurs peuvent se connecter plus rapidement et plus facilement, ce qui améliore leur satisfaction.
• Intégration frontend simple : L'une des fonctionnalités phares de la Conditional UI est sa facilité d'intégration. Les développeurs peuvent l'incorporer de manière transparente dans le frontend avec quelques lignes de code (voir ci-dessous).
• Connexion sans mot de passe et sans nom d'utilisateur : L'un des énormes avantages est que la Conditional UI promeut non seulement l'authentification sans mot de passe mais aussi une expérience sans nom d'utilisateur ou sans compte. Les utilisateurs sont épargnés de la charge mentale de se rappeler de leur adresse e-mail spécifique ou de leur pseudo d'utilisateur lors de l'inscription. À la place, ils peuvent s'appuyer sur les suggestions du navigateur, qui incluent l'adresse e-mail / le pseudo d'utilisateur associé à la clé d'accès appropriée dans le menu de remplissage automatique.
• Résolution du dilemme d'amorçage : La transition des systèmes traditionnels nom d'utilisateur-mot de passe vers les clés d'accès peut être intimidante. La Conditional UI aborde ce défi de transition. Les sites web peuvent initier un appel clé d'accès / WebAuthn en même temps qu'une invite de mot de passe classique sans s'inquiéter des éventuelles erreurs de boîte de dialogue modale si un appareil manque des identifiants nécessaires.

Abonnez-vous à notre Substack passkeys pour les dernières actualités.

S'abonner

• Courbe d'apprentissage pour les développeurs : La Conditional UI introduit un nouveau paradigme, ce qui signifie qu'il y a une courbe d'apprentissage impliquée pour les développeurs peu familiers avec ses subtilités.
• Dépendance à l'appareil / au navigateur : Le succès de la Conditional UI repose sur la compatibilité de l'appareil ou du navigateur de l'utilisateur. Étant donné que tous les navigateurs ou appareils ne la prennent pas en charge actuellement, cela peut limiter son application.
• Les gestionnaires de mots de passe désactivent le remplissage automatique : Certains gestionnaires de mots de passe modernes et leurs extensions de navigateur modifient le DOM du site web et désactivent ou remplacent la balise autocomplete dans les champs de saisie au profit de leurs propres fonctionnalités de remplissage automatique. Cela peut conduire à une expérience utilisateur incohérente et insatisfaisante. Comme les normes pour la Conditional UI sont relativement nouvelles, nous espérons que les choses s'amélioreront, afin que par ex. deux menus de remplissage automatique ne soient pas superposés ou que celui souhaité ne soit pas du tout affiché.

Dans la suite, nous fournissons une ventilation étape par étape des étapes individuelles d'un flux complet de Conditional UI :

En général, le flux de processus de la Conditional UI peut être divisé en deux phases. Pendant la phase de chargement de la page, la logique de la Conditional UI se produit en arrière-plan, tandis que dans la phase d'opération utilisateur, l'utilisateur doit activement faire quelque chose.

1. Vérification de la disponibilité de la Conditional UI : Le client (navigateur) appelle la fonction isConditionalMediationAvailable() pour détecter si la combinaison actuelle navigateur / appareil prend en charge la Conditional UI. Ce n'est que si la réponse est vraie que le processus continue, sinon le processus de la Conditional UI est annulé.
2. Appeler le point de terminaison de la Conditional UI : Ensuite, le client appelle le point de terminaison de la Conditional UI du serveur afin de récupérer les PublicKeyCredentialRequestOptions.
3. Recevoir les PublicKeyCredentialRequestOptions : Le serveur renvoie les PublicKeyCredentialRequestOptions qui contiennent le défi et d'autres options de serveur WebAuthn (par ex. allowCredentials, extensions, userVerification).
4. Démarrer l'authentification locale : En appelant credentials.get() avec les PublicKeyCredentialRequestOptions reçues et la propriété mediation définie pour être conditionnelle, le processus pour l'authentification locale sur l'appareil démarre.
5. Afficher la sélection de remplissage automatique : Le menu de remplissage automatique pour les clés d'accès s'affiche. Le style spécifique dépend du navigateur et de l'appareil (par ex. certains exigent que l'utilisateur place le curseur dans le champ de saisie, d'autres affichent automatiquement le menu au chargement de la page, voir ci-dessous).
6. Authentification locale de l'utilisateur : L'utilisateur sélectionne la clé d'accès dans le menu de remplissage automatique qu'il souhaite utiliser et s'authentifie via la boîte de dialogue d'authentification de son appareil (par ex. via Face ID, Touch ID, Windows Hello).
7. Envoyer la réponse de l'authentificateur au serveur : Si l'authentification locale de l'utilisateur a réussi, la réponse de l'authentificateur est renvoyée au serveur.
8. L'utilisateur est connecté et redirigé : Une fois que le serveur reçoit la réponse de l'authentificateur, il valide la signature avec la clé publique du compte utilisateur correspondant dans la base de données. Si la vérification réussit, l'utilisateur a accès, est connecté et redirigé vers la page de connexion.

En suivant ce flux de processus, la Conditional UI offre une expérience d'authentification fluide et conviviale.

Pour faire fonctionner la Conditional UI, certains aspects généraux doivent être pris en compte :

• Spécifications des identifiants : La Conditional UI est spécifiquement conçue pour fonctionner uniquement avec des clés résidentes / identifiants découvrables. La raison sous-jacente est que les authentificateurs ne stockent pas de données spécifiques à l'utilisateur (par ex., nom, nom d'affichage) pour les clés non résidentes / identifiants non découvrables. En conséquence, utiliser ces derniers pour le remplissage automatique des clés d'accès n'est pas possible.
• Filtrage des identifiants : La fonctionnalité allowCredentials reste prise en charge, facilitant les sites web qui connaissent déjà l'identité de l'utilisateur (par exemple, si un nom d'utilisateur a été envoyé lors de l'appel initial de médiation parce qu'il pourrait être stocké dans le LocalStorage des navigateurs) pour affiner la liste des identifiants présentés aux utilisateurs lors du remplissage automatique.

Rejoignez notre communauté passkeys pour les mises à jour et le support.

Rejoindre

Pour faire fonctionner la Conditional UI côté client, les exigences suivantes doivent être remplies :

• Navigateur compatible : Assurez-vous que l'utilisateur utilise un navigateur moderne qui prend en charge la Conditional UI (voir ici pour la couverture la plus récente des navigateurs).
• JavaScript activé : JavaScript doit être activé pour faciliter les opérations de la Conditional UI.
• Tester la disponibilité de la Conditional UI : La partie utilisatrice (le côté serveur) devrait avoir la certitude que la Conditional UI est disponible côté client, lorsqu'elle reçoit l'appel de médiation WebAuthn, pour éviter de déclencher des erreurs visibles par l'utilisateur dans les scénarios où la Conditional UI n'est pas prise en charge. Pour y remédier, il est recommandé d'utiliser la méthode isConditionalMediationAvailable() et de vérifier la disponibilité technique de la Conditional UI (voir ci-dessous pour plus de détails).
• Champ de saisie HTML requis : Pour que la Conditional UI fonctionne, vous devez avoir un champ de saisie HTML dans votre page web. Si vous n'en avez pas, vous devez fournir un support pour le processus de connexion classique par clé d'accès / WebAuthn qui est déclenché par une interaction utilisateur, comme un clic sur un bouton.
• Supprimer les protocoles de délai d'attente : Les paramètres de délai d'attente (par ex. l'utilisateur prend beaucoup de temps pour choisir une clé d'accès dans le menu de remplissage automatique) doivent être ignorés dans cette configuration.

Pour faire fonctionner la Conditional UI, certaines exigences côté serveur doivent également être remplies :

• Serveur WebAuthn en cours d'exécution : Comme nous sommes toujours dans le contexte des clés d'accès / WebAuthn, il est nécessaire d'avoir un serveur WebAuthn en cours d'exécution qui gère les procédures d'authentification.
• Fournir un point de terminaison de démarrage de médiation : Comparé aux points de terminaison de connexion WebAuthn classiques, il est utile de fournir un autre point de terminaison qui a une fonctionnalité similaire mais peut gérer un identifiant utilisateur facultatif (par ex. adresse e-mail, numéro de téléphone, nom d'utilisateur).

Depuis le déploiement officiel de la Conditional UI fin 2022 et les versions bêta antérieures, nous l'avons testée et avons beaucoup travaillé avec. Dans la suite, nous souhaitons partager avec vous des conseils pratiques qui ont aidé lors de l'implémentation de la Conditional UI.

Expérimentez les parcours passkey dans le Passkeys Debugger.

Essayer gratuitement

Un exemple de code minimaliste et complet pour une méthode de Conditional UI ressemblerait à ceci :

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Conditional UI</title>
    </head>
    <body>
        <input type="text" id="username" autocomplete="username webauthn" />
 
        <script>
            async function passkeyLogin() {
                try {
                    // retrieve the request options (incl. the challenge) from the WebAuthn server
                    let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
                    const credential = await navigator.credentials.get({
                        publicKey: options.publicKeyCredentialRequestOptions,
                        mediation: "conditional",
                    });
 
                    const userData = await WebAuthnClient.sendSignedChallenge(credential);
                    window.location.href = "/logged-in";
                } catch (error) {
                    console.log(error);
                }
            }
 
            passkeyLogin();
        </script>
    </body>
</html>

Implémentez une détection de la Conditional UI qui garantit que la Conditional UI n'est utilisée que lorsque la combinaison actuelle appareil / navigateur la prend en charge. Cela devrait fonctionner sans présenter d'erreurs visibles par l'utilisateur en l'absence de prise en charge de la Conditional UI. L'intégration de la méthode isConditionalMediationAvailable() dans l'interface utilisateur répond à cette préoccupation. Si la prise en charge de la Conditional UI est confirmée, le processus de connexion par Conditional UI peut être démarré.

// source: https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/isConditionalMediationAvailable#examples
 
// Availability of `window.PublicKeyCredential` means WebAuthn is usable.
if (window.PublicKeyCredential && PublicKeyCredential.isConditionalMediationAvailable) {
    // Check if conditional mediation is available.
    const isCMA = await PublicKeyCredential.isConditionalMediationAvailable();
    if (isCMA) {
        // Call WebAuthn authentication start endpoint
 
        let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
        const credential = await navigator.credentials.get({
            publicKey: options.publicKeyCredentialRequestOptions,
            mediation: "conditional",
        });
        /*
        ...
        */
    }
}

Le champ de saisie doit recevoir un jeton de remplissage automatique HTML webauthn. Cela signale au client de remplir les clés d'accès à la demande en cours. Outre les clés d'accès, d'autres valeurs de remplissage automatique peuvent également être présentées. Ces jetons de remplissage automatique peuvent être associés à d'autres jetons existants, par ex. :

• autocomplete="username webauthn" : Outre l'affichage des clés d'accès, cela suggère également le remplissage automatique du nom d'utilisateur.
• autocomplete="current-password webauthn" : Outre l'affichage des clés d'accès, cela propose également le remplissage automatique du mot de passe.

<label for="name">Username:</label>
<input type="text" name="name" autocomplete="username webauthn" />
<label for="password">Password:</label>
<input type="password" name="password" autocomplete="current-password webauthn" />

Pour plus de détails, nous recommandons de lire cet article de blog qui fournit plus de détails sur les jetons de remplissage / saisie automatique pour les clés d'accès et les mots de passe.

Pour récupérer les clés d'accès disponibles après avoir reçu l'objet PublicKeyCredentialRequestOptions, la fonction navigator.credentials.get() doit être appelée (qui sert à la fois les clés d'accès et les mots de passe). L'objet PublicKeyCredentialRequestOptions doit avoir le paramètre de médiation (mediation) défini sur conditionnel (conditional) pour activer la Conditional UI sur le client. Pour les cas où vous souhaitez plutôt une invite de clé d'accès modale, consultez la médiation immédiate.

const credential = await navigator.credentials.get({
    publicKey: options.publicKeyCredentialRequestOptions,
    mediation: "conditional",
});

S'il n'y a pas de clé d'accès disponible, ou si l'utilisateur ignore les clés d'accès suggérées et saisit son e-mail, le flux de la Conditional UI est arrêté. Cela souligne l'importance de toujours prendre en charge également la connexion classique par clé d'accès / WebAuthn via une modale.

Un point critique à souligner ici est la nécessité potentielle d'interrompre une requête de Conditional UI en cours. Contrairement aux expériences modales, les menus de remplissage automatique n'ont pas de bouton d'annulation. Selon la conception de WebAuthn, une seule requête d'identifiant active doit être en cours à un moment donné. La norme WebAuthn suggère d'utiliser un AbortController pour annuler un processus WebAuthn, applicable aux processus de connexion réguliers et de Conditional UI (voir ici pour plus de détails).

Dans la télémétrie de production, ce chemin d'annulation est souvent un résultat attendu du flux de contrôle, et non une défaillance du système. Si vous observez de grands volumes d'erreurs, vous devez classer les cas attendus par rapport aux cas inattendus selon le type d'opération et le timing avant de les traiter comme des régressions (voir les erreurs WebAuthn).

Le processus de connexion par Conditional UI est activé dès qu'un utilisateur arrive sur la page. La tâche initiale devrait être de créer un objet AbortController à portée globale. Cela agira comme un signal pour votre client afin de terminer la demande de remplissage automatique, surtout si l'utilisateur décide de suivre le processus régulier de connexion par clé d'accès. Assurez-vous que l'AbortController peut être invoqué par d'autres fonctions et est réinitialisé si le processus de la Conditional UI doit redémarrer. Utilisez la propriété signal dans l'appel navigator.credentials.get(), en incorporant le signal de votre AbortController comme valeur. Cela signale à la fonction clé d'accès / WebAuthn que la requête doit être interrompue si le signal est annulé. N'oubliez pas de configurer un nouvel AbortController chaque fois que vous déclenchez la Conditional UI. L'utilisation d'un AbortController déjà annulé entraînera une annulation instantanée de la fonction clé d'accès / WebAuthn. Les étapes restantes s'alignent sur un processus régulier de connexion par clé d'accès. Ci-dessous, vous voyez un exemple de code des étapes mentionnées :

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Conditional UI</title>
    </head>
    <body>
        <input type="text" id="username" autocomplete="username webauthn" />
 
        <script>
            async function passkeyLogin() {
                try {
                    // retrieve the request options (incl. the challenge) from the WebAuthn server
                    let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
                    const credential = await navigator.credentials.get({
                        publicKey: options.publicKeyCredentialRequestOptions,
                        mediation: "conditional",
                    });
 
                    const userData = await WebAuthnClient.sendSignedChallenge(credential);
                    window.location.href = "/logged-in";
                } catch (error) {
                    console.log(error);
                }
            }
 
            passkeyLogin();
        </script>
    </body>
</html>

En l'absence de prise en charge de la Conditional UI, dirigez les utilisateurs vers le processus classique de connexion par clé d'accès. Offrir ce chemin est important pour les utilisateurs s'appuyant sur des clés de sécurité matérielles (par ex. YubiKeys) ou ceux contraints d'utiliser des clés non résidentes / identifiants non découvrables en raison des contraintes de l'authentificateur.

Découvrez combien de personnes utilisent réellement les passkeys.

Voir les données d'adoption

Lorsque vous développez une application native, par ex. pour iOS ou Android, la Conditional UI fonctionne également. Peu importe si vous l'implémentez de manière native dans Flutter, Kotlin ou Swift, ou si vous décidez d'utiliser les Chrome Custom Tabs (CCT) ou SFSafariViewController ou SFAuthenticationSession / ASWebAuthenticationSession. Les deux approches prennent en charge la Conditional UI.

En général, nous n'avons trouvé presque aucune documentation sur la façon d'implémenter la prise en charge de la Conditional UI pour les applications iOS. Lors de nos recherches, cependant, nous avons découvert deux façons d'ajouter la prise en charge de la Conditional UI à une application iOS, car l'expérience utilisateur différera également.

Type A : Superposition / Popup sur presque tout l'écran

Le premier type A montre une superposition / popup qui s'étend sur presque tout l'écran. Ici, vous verrez toutes les clés d'accès disponibles pour cette partie utilisatrice. Un exemple marquant qui implémente la Conditional UI de cette manière est KAYAK. La superposition / popup apparaît automatiquement, lorsque l'utilisateur ouvre le bon écran.

Type B : Remplissage automatique du clavier

Le second type B affiche une clé d'accès appropriée dans la section de remplissage automatique du clavier (où des mots de passe sont également suggérés pour le remplissage automatique). Cliquer sur la valeur suggérée effectuera l'authentification Face ID et vous permettra de vous connecter. Dans la version actuelle de l'application iOS du panel développeur Corbado, nous l'avons implémenté de cette manière (voir le message de connexion par clé d'accès pour <relying party ID> avec le nom d'utilisateur WebAuthn). Pour qu'il s'affiche, l'utilisateur doit appuyer dans le champ de saisie :

Cette fonctionnalité de remplissage automatique des clés d'accès dans la section du clavier peut rencontrer des problèmes lorsque l'iOS est fraîchement installé car apparemment une sorte de mise en cache se produit en arrière-plan et recherche toutes les clés d'accès disponibles pour cette partie utilisatrice.

Cliquer sur l'icône de clé à droite de la clé d'accès suggérée mène au site connu pour le choix des mots de passe / clés d'accès sous iOS :

Veuillez noter que nous n'avons pas trouvé de documentation officielle, et nos informations sont basées sur nos expériences et hypothèses plutôt que sur une preuve concrète de l'implémentation adéquate.

Sur Android, l'histoire de la Conditional UI est un peu plus claire, car il n'y a qu'un seul type pour la Conditional UI / remplissage automatique de clés d'accès qui exploite l'API Credential Manager d'Android (voir la documentation ici). Parce que les fournisseurs Android peuvent différer, surveillez les erreurs de clés d'accès du Credential Manager séparément des modèles d'échec WebAuthn uniquement sur navigateur.

Ouvrir la page où la Conditional UI est implémentée affiche l'écran suivant, où vous trouverez différentes façons de vous connecter :

Cliquer sur More saved sign-ins (Plus de connexions enregistrées) fournit plus d'options pour choisir la connexion (y compris l'authentification multi-appareils et la sélection d'une plateforme de synchronisation de clés d'accès différente, par ex. Samsung Pass ou 1Password) :

Pour illustrer à quoi ressemble la Conditional UI pour l'utilisateur final, nous avons ajouté plusieurs captures d'écran d'un menu de remplissage automatique de la Conditional UI en utilisant https://passkeys.eu.

Testez les passkeys dans une démo en direct.

Tester les passkeys

Jetons un coup d'œil à quelques scénarios courants dans les applications de la vie réelle.

Si aucune clé d'accès n'est enregistrée pour un site, la Conditional UI se comportera différemment selon le navigateur et le système d'exploitation.

Sur Chrome sous macOS, cliquer dans le champ de saisie affiche un menu déroulant de remplissage automatique vide :

Sur Safari sous macOS, aucun menu déroulant n'est affiché - juste une icône discrète dans le champ de saisie :

Sur Android ou iOS, l'interface de remplissage automatique n'apparaît que si l'utilisateur appuie dans le champ et que l'OS trouve des identifiants correspondants.

Cette variabilité est intentionnelle et fait partie du modèle de confidentialité de WebAuthn : les sites web ne peuvent pas détecter si l'utilisateur possède une clé d'accès à moins que l'utilisateur n'en sélectionne activement une.

Si un utilisateur a installé plusieurs fournisseurs de clés d'accès (par ex. Trousseau iCloud, Google Password Manager, 1Password), le navigateur ou l'OS va généralement utiliser par défaut le gestionnaire d'identifiants principal de l'utilisateur.

Pour une liste des différents fournisseurs de clés d'accès / gestionnaires d'identifiants prenant en charge les clés d'accès, nous vous recommandons de consulter le lien GitHub suivant.

Sur Android, le Credential Manager expose différents fournisseurs comme Samsung Pass ou 1Password.

1. En cliquant sur le champ de saisie de l'identifiant utilisateur, ce menu apparaît où l'utilisateur peut sélectionner une clé d'accès.

2. Si l'utilisateur a cliqué sur "Plus de clés d'accès" dans l'écran précédent, une présélection d'autres fournisseurs de clés d'accès / gestionnaires d'identifiants et de clés d'accès apparaît :

3. Si l'utilisateur a cliqué sur "Plus de connexions enregistrées" dans l'écran précédent, une liste complète de choix disponibles apparaît où l'utilisateur peut sélectionner une clé d'accès.

Sur iOS, l'icône de clé ouvre la liste complète des clés d'accès de diverses sources.

1. Dans un premier temps, sur iOS 18+, la Conditional UI classique avec le fournisseur de clés d'accès par défaut apparaît.

2. Lors du clic sur l'icône de clavier, le menu de sélection suivant apparaît.

3. Après avoir sélectionné un gestionnaire d'identifiants / fournisseur de clés d'accès, l'utilisateur peut sélectionner la clé d'accès à utiliser.

Les clés d'accès, avec leur capacité de Conditional UI / remplissage automatique, constituent la nouvelle façon de s'authentifier en ligne. Alors que nous passons à une ère où les mots de passe sont de plus en plus remplacés par des clés d'accès, le besoin de mécanismes de transition robustes et conviviaux est indéniable. Cet article a aidé à comprendre comment implémenter correctement la Conditional UI, une grande aide dans le processus de transition, et sur quels aspects porter une attention particulière.

À propos de Corbado

Corbado est la Passkey Intelligence Platform pour les équipes CIAM qui gèrent l'authentification client à grande échelle. Nous vous montrons ce que les logs IDP et les outils d'analytics génériques ne voient pas : quels appareils, versions d'OS, navigateurs et gestionnaires de credentials prennent en charge les passkeys, pourquoi les enrôlements ne deviennent pas des connexions, où le flux WebAuthn échoue et quand une mise à jour OS ou navigateur casse silencieusement la connexion, le tout sans remplacer Okta, Auth0, Ping, Cognito ni votre IDP interne. Deux produits : Corbado Observe ajoute l'observabilité pour les passkeys et toute autre méthode de connexion. Corbado Connect apporte des passkeys managés avec analytics intégrés (aux côtés de votre IDP). VicRoads gère les passkeys pour plus de 5M d'utilisateurs avec Corbado (+80 % d'activation passkey). Parler à un expert Passkey →

Appelez PublicKeyCredential.isConditionalMediationAvailable() et ne continuez que si cela renvoie true (vrai). Cette vérification évite des erreurs visibles par l'utilisateur sur les combinaisons de navigateurs et d'appareils non prises en charge. La méthode doit être évaluée à chaque chargement de page avant d'appeler navigator.credentials.get() avec mediation: "conditional".

Les authentificateurs ne stockent les données spécifiques à l'utilisateur, telles que le nom et le nom d'affichage, que pour les clés résidentes (identifiants découvrables). Les clés non résidentes ne conservent pas ces informations, le menu de remplissage automatique ne peut donc pas renseigner les détails du compte à sélectionner par l'utilisateur.

Le comportement varie selon la plateforme. Chrome sous macOS affiche une liste déroulante de remplissage automatique vide, Safari sous macOS affiche uniquement une icône discrète dans le champ de saisie, et sur Android ou iOS, l'interface de remplissage automatique n'apparaît que si l'OS trouve des identifiants correspondants après que l'utilisateur a appuyé sur le champ. Cette variabilité est intentionnelle et fait partie du modèle de confidentialité de WebAuthn : les sites web ne peuvent pas détecter si une clé d'accès existe à moins que l'utilisateur n'en sélectionne activement une.

Créez un AbortController à portée globale et passez son signal à navigator.credentials.get(). Appelez .abort() sur le contrôleur lorsque l'utilisateur initie un flux de connexion modale. Instanciez toujours un nouvel AbortController chaque fois que la Conditional UI redémarre, car la réutilisation d'un contrôleur déjà annulé provoque l'annulation immédiate de la requête WebAuthn.

La Conditional UI fonctionne à la fois dans les applications natives iOS et Android. iOS prend en charge deux variantes : une popup en superposition plein écran et une suggestion de remplissage automatique au clavier. Android utilise l'API Credential Manager, qui peut afficher les clés d'accès de multiples fournisseurs tels que Samsung Pass ou 1Password.