Passkey et WebAuthn : login sans mot de passe, sans magie

spinny:~/writing $ less passkeys-webauthn-passwordless-authentication.md

1 
2Les mots de passe font partie de ces choses que nous avons normalisées simplement parce que nous vivons avec eux depuis des années. Les utilisateurs les oublient, les réutilisent, les écrivent là où ils ne devraient pas. Les équipes doivent gérer les réinitialisations, les politiques, les hachages, les fuites, le phishing et le support.
3 
4Les passkey ne rendent pas l'authentification parfaite, mais ils suppriment un énorme problème : le serveur n'a plus besoin de garder un secret partagé avec l'utilisateur.
5 
6## Que se passe-t-il réellement
7 
8Un passkey est un identifiant basé sur WebAuthn. Lorsque l'utilisateur le crée, l'appareil génère une bi-clé :
9 
10- une clé privée, qui reste sur l'appareil ou dans le gestionnaire de mots de passe ;
11- une clé publique, que le serveur peut sauvegarder.
12 
13Lors de la connexion, le serveur ne demande pas "dites-moi le mot de passe". Envoyez un défi aléatoire. L'appareil le signe avec la clé privée. Le serveur vérifie la signature avec la clé publique.
14 
15C'est ce qui est intéressant : si la base de données est volée, il n'y a aucun mot de passe à déchiffrer. Et si un utilisateur se retrouve sur un faux domaine, le passkey n'est pas valable pour ce domaine. Ce n'est pas seulement une question de commodité, c'est une protection concrète contre le phishing.
16 
17## Le navigateur fait office de pont
18 
19Dans le navigateur, les deux API principaux sont :
20 
21- `navigator.credentials.create()` pour créer un passkey ;
22- `navigator.credentials.get()` pour l'utiliser lors de la connexion.
23 
24Mais la logique importante réside dans le serveur. Le serveur doit générer le challenge, le sauvegarder temporairement, vérifier la réponse, vérifier la source et Relying Party ID, puis créer la session.
25 
26La partie client devrait être presque ennuyeuse :
27 
28```typescript
29const options = await fetch('/api/passkeys/login/options').then((r) => r.json());
30 
31const credential = await navigator.credentials.get({
32  publicKey: PublicKeyCredential.parseRequestOptionsFromJSON(options),
33});
34 
35await fetch('/api/passkeys/login/verify', {
36  method: 'POST',
37  headers: { 'Content-Type': 'application/json' },
38  body: JSON.stringify(credential?.toJSON()),
39});
40```
41 
42Si vous vous retrouvez à mettre en œuvre le chiffrement WebAuthn à la main, arrêtez. Utilisez une bibliothèque robuste côté serveur. Les erreurs ici ne sont pas des "bugs mignons", ce sont des trous d'authentification.
43 
44## Que sauvegarder dans la base de données
45 
46Il n’est pas nécessaire de sauver la moitié du monde. Généralement suffisant :
47 
48- ID du titre de compétences ;
49- clé publique ;
50- utilisateur connecté ;
51- tout compteur de vérification ou métadonnées ;
52- les transports, si utiles pour l'UX ;
53- nom choisi par l'utilisateur ;
54- date de création et dernière utilisation.
55 
56Un tableau minimal pourrait ressembler à ceci :
57 
58```sql
59create table passkey_credentials (
60  id uuid primary key default gen_random_uuid(),
61  user_id uuid not null references users(id),
62  credential_id text not null unique,
63  public_key text not null,
64  name text,
65  created_at timestamptz not null default now(),
66  last_used_at timestamptz
67);
68```
69 
70Ensuite, j'ajouterais des journaux d'audit et des notifications : si quelqu'un crée un nouveau passkey sur mon compte, je veux en être informé.
71 
72## L'UX compte plus que la démo
73 
74La démo d'un passkey est toujours belle : vous cliquez, Face ID, vous y êtes. Le produit lui-même est plus compliqué.
75 
76Quelqu'un change de téléphone. Quelqu'un utilise un ordinateur d'entreprise verrouillé. Certaines personnes ne comprennent pas pourquoi le navigateur suggère un passkey. Quelqu'un perd l'accès à son appareil.
77 
78C'est pourquoi je ne commencerais pas par "à partir d'aujourd'hui, plus de mots de passe pour tout le monde". Je commencerais comme ça :
79 
801. passkey facultatif pour les utilisateurs internes ;
812. suggestion d'en créer un après une connexion réussie ;
823. page du compte pour renommer et supprimer passkey ;
834. repli clair ;
845. déploiement progressif dans la connexion principale.
85 
86Le texte dans l'interface doit être simple. "Utilisez l'écran de verrouillage de votre appareil" est préférable à "authentifiez-vous avec un identifiant de résident FIDO2".
87 
88## Erreurs que j'éviterais
89 
90Ne génèrez pas de défis sur le client. Le challenge est créé sur le serveur et ne doit être vérifié qu'une seule fois.
91 
92Ne vous contentez pas de l'identifiant des informations d'identification. Vous devez vérifier la signature, le défi, l'origine et le Relying Party ID.
93 
94Ne supprimez pas les solutions de secours avant d'avoir un bon flux de récupération. Le sans mot de passe ne doit pas nécessairement devenir « si vous perdez votre téléphone, vous êtes absent pour toujours ».
95 
96Ne traitez pas le passkey comme un bouton purement frontal. Cacher un bouton n’est pas une question de sécurité : la véritable vérification se fait côté serveur.
97 
98## Passkey-first ou passkey-friendly ?
99 
100Pour un nouveau produit, vous pouvez penser d'abord passkey. Pour une application existante, je préfère la compatibilité passkey : ajoutez passkey comme méthode recommandée, mesurez le succès et les problèmes, puis réduisez calmement le poids du mot de passe.
101 
102La migration idéale ne se fait pas sentir. L'utilisateur découvre que la connexion est plus facile, mais que l'entreprise n'a pas modifié son protocole d'authentification.
103 
104## Conclusion
105 
106Les passkey sont intéressants car ils améliorent à la fois la sécurité et l’UX, ce qui est rare. Ce n’est pas une baguette magique : la récupération, la compatibilité, le support et le déploiement restent à bien concevoir.
107 
108Mais le changement fondamental est fort. Arrêtez de demander aux utilisateurs d’inventer et de protéger des secrets. Vous laissez l'appareil signer une preuve cryptographique liée à votre domaine. Moins de mémoire humaine, moins de phishing, moins de réinitialisations de mots de passe. Je dirais qu'ils valent la peine d'être pris au sérieux.
109 
110##Sources
111 
112- [MDN: Passkeys](https://developer.mozilla.org/en-US/docs/Web/Security/Authentication/Passkeys)
113- [MDN: Web Authentication API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API)
114- [W3C: Web Authentication](https://www.w3.org/TR/webauthn-3/)
115- [passkeys.dev](https://passkeys.dev/)
116

:Passkey et WebAuthn : login sans mot de passe, sans magielines 1-116 (END) — press q to close

2Les mots de passe font partie de ces choses que nous avons normalisées simplement parce que nous vivons avec eux depuis des années. Les utilisateurs les oublient, les réutilisent, les écrivent là où ils ne devraient pas. Les équipes doivent gérer les réinitialisations, les politiques, les hachages, les fuites, le phishing et le support.

4Les passkey ne rendent pas l'authentification parfaite, mais ils suppriment un énorme problème : le serveur n'a plus besoin de garder un secret partagé avec l'utilisateur.

6## Que se passe-t-il réellement

8Un passkey est un identifiant basé sur WebAuthn. Lorsque l'utilisateur le crée, l'appareil génère une bi-clé :

10- une clé privée, qui reste sur l'appareil ou dans le gestionnaire de mots de passe ;

11- une clé publique, que le serveur peut sauvegarder.

13Lors de la connexion, le serveur ne demande pas "dites-moi le mot de passe". Envoyez un défi aléatoire. L'appareil le signe avec la clé privée. Le serveur vérifie la signature avec la clé publique.

15C'est ce qui est intéressant : si la base de données est volée, il n'y a aucun mot de passe à déchiffrer. Et si un utilisateur se retrouve sur un faux domaine, le passkey n'est pas valable pour ce domaine. Ce n'est pas seulement une question de commodité, c'est une protection concrète contre le phishing.

17## Le navigateur fait office de pont

19Dans le navigateur, les deux API principaux sont :

21- `navigator.credentials.create()` pour créer un passkey ;

22- `navigator.credentials.get()` pour l'utiliser lors de la connexion.

24Mais la logique importante réside dans le serveur. Le serveur doit générer le challenge, le sauvegarder temporairement, vérifier la réponse, vérifier la source et Relying Party ID, puis créer la session.

26La partie client devrait être presque ennuyeuse :

28```typescript

29const options = await fetch('/api/passkeys/login/options').then((r) => r.json());

31const credential = await navigator.credentials.get({

32 publicKey: PublicKeyCredential.parseRequestOptionsFromJSON(options),

33});

35await fetch('/api/passkeys/login/verify', {

36 method: 'POST',

37 headers: { 'Content-Type': 'application/json' },

38 body: JSON.stringify(credential?.toJSON()),

39});

40```

42Si vous vous retrouvez à mettre en œuvre le chiffrement WebAuthn à la main, arrêtez. Utilisez une bibliothèque robuste côté serveur. Les erreurs ici ne sont pas des "bugs mignons", ce sont des trous d'authentification.

44## Que sauvegarder dans la base de données

46Il n’est pas nécessaire de sauver la moitié du monde. Généralement suffisant :

48- ID du titre de compétences ;

49- clé publique ;

50- utilisateur connecté ;

51- tout compteur de vérification ou métadonnées ;

52- les transports, si utiles pour l'UX ;

53- nom choisi par l'utilisateur ;

54- date de création et dernière utilisation.

56Un tableau minimal pourrait ressembler à ceci :

58```sql

59create table passkey_credentials (

60 id uuid primary key default gen_random_uuid(),

61 user_id uuid not null references users(id),

62 credential_id text not null unique,

63 public_key text not null,

64 name text,

65 created_at timestamptz not null default now(),

66 last_used_at timestamptz

67);

68```

70Ensuite, j'ajouterais des journaux d'audit et des notifications : si quelqu'un crée un nouveau passkey sur mon compte, je veux en être informé.

72## L'UX compte plus que la démo

74La démo d'un passkey est toujours belle : vous cliquez, Face ID, vous y êtes. Le produit lui-même est plus compliqué.

76Quelqu'un change de téléphone. Quelqu'un utilise un ordinateur d'entreprise verrouillé. Certaines personnes ne comprennent pas pourquoi le navigateur suggère un passkey. Quelqu'un perd l'accès à son appareil.

78C'est pourquoi je ne commencerais pas par "à partir d'aujourd'hui, plus de mots de passe pour tout le monde". Je commencerais comme ça :

801. passkey facultatif pour les utilisateurs internes ;

812. suggestion d'en créer un après une connexion réussie ;

823. page du compte pour renommer et supprimer passkey ;

834. repli clair ;

845. déploiement progressif dans la connexion principale.

86Le texte dans l'interface doit être simple. "Utilisez l'écran de verrouillage de votre appareil" est préférable à "authentifiez-vous avec un identifiant de résident FIDO2".

88## Erreurs que j'éviterais

90Ne génèrez pas de défis sur le client. Le challenge est créé sur le serveur et ne doit être vérifié qu'une seule fois.

92Ne vous contentez pas de l'identifiant des informations d'identification. Vous devez vérifier la signature, le défi, l'origine et le Relying Party ID.

94Ne supprimez pas les solutions de secours avant d'avoir un bon flux de récupération. Le sans mot de passe ne doit pas nécessairement devenir « si vous perdez votre téléphone, vous êtes absent pour toujours ».

96Ne traitez pas le passkey comme un bouton purement frontal. Cacher un bouton n’est pas une question de sécurité : la véritable vérification se fait côté serveur.

98## Passkey-first ou passkey-friendly ?

100Pour un nouveau produit, vous pouvez penser d'abord passkey. Pour une application existante, je préfère la compatibilité passkey : ajoutez passkey comme méthode recommandée, mesurez le succès et les problèmes, puis réduisez calmement le poids du mot de passe.

101

102La migration idéale ne se fait pas sentir. L'utilisateur découvre que la connexion est plus facile, mais que l'entreprise n'a pas modifié son protocole d'authentification.

103

104## Conclusion

105

106Les passkey sont intéressants car ils améliorent à la fois la sécurité et l’UX, ce qui est rare. Ce n’est pas une baguette magique : la récupération, la compatibilité, le support et le déploiement restent à bien concevoir.

107

108Mais le changement fondamental est fort. Arrêtez de demander aux utilisateurs d’inventer et de protéger des secrets. Vous laissez l'appareil signer une preuve cryptographique liée à votre domaine. Moins de mémoire humaine, moins de phishing, moins de réinitialisations de mots de passe. Je dirais qu'ils valent la peine d'être pris au sérieux.

109

110##Sources

111

112- [MDN: Passkeys](https://developer.mozilla.org/en-US/docs/Web/Security/Authentication/Passkeys)

113- [MDN: Web Authentication API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API)

114- [W3C: Web Authentication](https://www.w3.org/TR/webauthn-3/)

115- [passkeys.dev](https://passkeys.dev/)

116