Check-up sur la détection de fonctionnalités de l'API de gestion des identifiants

Eiji Kitamura

Résumé

WebAuthn contribue à renforcer la sécurité en proposant sur le Web l'authentification basée sur les identifiants par clé publique. Cet outil sera bientôt compatible avec Chrome, Firefox et Edge (avec les nouvelles spécifications). Il ajoute un nouveau type d'objet Credential, qui peut toutefois endommager les sites Web qui utilisent l'API de gestion des identifiants sans détecter les types d'identifiants spécifiques qu'ils utilisent.

Si vous le faites actuellement pour la détection de fonctionnalités

if (navigator.credentials && navigator.credentials.preventSilentAccess) {
    // use CM API
}

À la place, procédez comme suit :

if (window.PasswordCredential || window.FederatedCredential) {
    // Call navigator.credentials.get() to retrieve stored
    // PasswordCredentials or FederatedCredentials.
}

if (window.PasswordCredential) {
    // Get/Store PasswordCredential
}

if (window.FederatedCredential) {
    // Get/Store FederatedCredential
}

if (navigator.credentials && navigator.credentials.preventSilentAccess) {
    // Call navigator.credentials.preventSilentAccess()
}

Consultez les modifications apportées à l'exemple de code pour en savoir plus.

Pour en savoir plus, poursuivez votre lecture !

Remarque : Si vous utilisez l'identité Google comme principal moyen de connexion de vos utilisateurs, envisagez d'utiliser la bibliothèque JavaScript de connexion automatique et d'inscription en un seul geste basée sur l'API Gestion des identifiants. Elle combine la connexion Google et la connexion par mot de passe en un seul appel d'API, et permet de créer des comptes en un seul geste.

Qu'est-ce que l'API Credential Management ?

L'API Credential Management (API CM) permet aux sites Web d'accéder de manière programmatique au magasin d'identifiants du user-agent pour stocker/récupérer les identifiants utilisateur pour l'origine d'appel.

Les API de base sont les suivantes :

• navigator.credentials.get()
• navigator.credentials.store()
• navigator.credentials.create()
• navigator.credentials.preventSilentAccess()

La spécification d'origine de l'API CM définit deux types d'identifiants :

• PasswordCredential
• FederatedCredential

PasswordCredential est un identifiant qui contient l'ID et le mot de passe de l'utilisateur. FederatedCredential est un identifiant qui contient l'ID de l'utilisateur et une chaîne représentant un fournisseur d'identité.

Grâce à ces deux identifiants, les sites Web peuvent :

• Autorisez l'utilisateur à se connecter avec des identifiants basés sur un mot de passe ou fédérés précédemment enregistrés dès qu'il accède à la page (connexion automatique).
• Stockez les identifiants basés sur un mot de passe ou fédérés avec lesquels l'utilisateur s'est connecté.
• Maintenez les identifiants de connexion de l'utilisateur à jour (par exemple, après un changement de mot de passe).

Qu'est-ce que WebAuthn ?

WebAuthn (Web Authentication) ajoute des identifiants de clé publique à l'API CM. Par exemple, il offre aux sites Web une méthode standardisée pour implémenter l'authentification à deux facteurs à l'aide d'appareils d'authentification compatibles avec FIDO 2.0.

Sur le plan technique, WebAuthn étend l'API CM avec l'interface PublicKeyCredential.

Quel est le problème ?

Auparavant, nous conseillions aux développeurs de détecter la fonctionnalité de l'API CM avec le code suivant :

if (navigator.credentials && navigator.credentials.preventSilentAccess) {
  // Use CM API
}

But as you can see from the descriptions above, the `navigator.credentials` is
now expanded to support public-key credentials in addition to password
credentials and federated credentials.

The problem is that user agents don't necessarily support all kinds of
credentials. If you continue feature detect using `navigator.credentials`, your
website may break when you are using a certain credential type not supported by
the browser.

**Supported credential types by browsers**
<table class="properties with-heading-tint"><tbody><tr>
<th></th>
<th>PasswordCredential / FederatedCredential</th>
<th>PublicKeyCredential</th>
</tr><tr><th>Chrome
</th><td>Available
</td><td>In development
</td></tr><tr><th>Firefox
</th><td>N/A
</td><td>Aiming to ship on 60
</td></tr><tr><th>Edge
</th><td>N/A
</td><td>Implemented with <a href="https://blogs.windows.com/msedgedev/2016/04/12/a-world-without-passwords-windows-hello-in-microsoft-edge/">older API</a>. New API (navigator.credentials) coming soon.
</td></tr></tbody></table>


## The solution
You can avoid this by modifying feature detection code as follows to explicitly
test for the credential type that you intend to use.

```js
if (window.PasswordCredential || window.FederatedCredential) {
    // Call navigator.credentials.get() to retrieve stored
    // PasswordCredentials or FederatedCredentials.
}

if (window.PasswordCredential) {
    // Get/Store PasswordCredential
}

if (window.FederatedCredential) {
    // Get/Store FederatedCredential
}

if (navigator.credentials && navigator.credentials.preventSilentAccess) {
    // Call navigator.credentials.preventSilentAccess()
}

Consultez les modifications réelles apportées à l'exemple de code à titre d'exemple.

Pour référence, voici comment détecter les PublicKeyCredential ajoutées dans WebAuthn :

if (window.PublicKeyCredential) {
    // use CM API with PublicKeyCredential added in the WebAuthn spec
}

Chronologie

La première implémentation disponible de WebAuthn est Firefox, et elle devrait être stable vers le début du mois de mai 2018.

Enfin

Si vous avez des questions, envoyez-les à @agektmr ou à [e-mail].