Passkey en WebAuthn: inloggen zonder wachtwoord, zonder magie

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

1 
2Wachtwoorden zijn een van die dingen die we hebben genormaliseerd, alleen maar omdat we er al jaren mee leven. Gebruikers vergeten ze, hergebruiken ze, schrijven ze waar ze niet mogen. Teams moeten resets, beleid, hashes, lekken, phishing en ondersteuning beheren.
3 
4De passkey maken de authenticatie niet perfect, maar ze nemen een groot probleem weg: de server hoeft niet langer een geheim te bewaren dat met de gebruiker wordt gedeeld.
5 
6## Wat er echt gebeurt
7 
8Een passkey is een referentie gebaseerd op WebAuthn. Wanneer de gebruiker het aanmaakt, genereert het apparaat een sleutelpaar:
9 
10- een privésleutel, die op het apparaat of in de wachtwoordbeheerder blijft staan;
11- een publieke sleutel, die de server kan opslaan.
12 
13Bij het inloggen vraagt de server niet "vertel mij het wachtwoord". Stuur een willekeurige uitdaging. Het apparaat ondertekent het met de privésleutel. De server verifieert de handtekening met de publieke sleutel.
14 
15Dat is het leuke: als de database wordt gestolen, zijn er geen wachtwoorden meer om te kraken. En als een gebruiker op een nepdomein terechtkomt, is de passkey niet geldig voor dat domein. Het is niet alleen gemak, het is concrete bescherming tegen phishing.
16 
17## De browser fungeert als een brug
18 
19In de browser zijn de twee belangrijkste API:
20 
21- `navigator.credentials.create()` om een passkey te maken;
22- `navigator.credentials.get()` om het te gebruiken tijdens het inloggen.
23 
24Maar de belangrijke logica zit op de server. De server moet de uitdaging genereren, deze tijdelijk opslaan, het antwoord verifiëren, de bron en Relying Party ID controleren en vervolgens de sessie creëren.
25 
26Het klantgedeelte zou bijna saai moeten zijn:
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 
42Als u merkt dat u WebAuthn-codering handmatig implementeert, stop dan. Gebruik een robuuste server-side bibliotheek. De fouten hier zijn geen "schattige bugs", het zijn authenticatiegaten.
43 
44## Wat u in de database moet opslaan
45 
46Het is niet nodig om de halve wereld te redden. Meestal genoeg:
47 
48- ID van de identificatie;
49- publieke sleutel;
50- aangesloten gebruiker;
51- eventuele verificatieteller of metadata;
52- transporten, indien nuttig voor de UX;
53- naam gekozen door de gebruiker;
54- aanmaakdatum en laatste gebruik.
55 
56Een minimale tabel zou er als volgt uit kunnen zien:
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 
70Vervolgens zou ik auditlogboeken en meldingen toevoegen: als iemand een nieuwe passkey op mijn account aanmaakt, wil ik daarvan op de hoogte zijn.
71 
72## UX is belangrijker dan demo
73 
74De demo van een passkey is altijd mooi: je klikt, Face ID, je doet mee. Het eigenlijke product is ingewikkelder.
75 
76Iemand verandert van telefoon. Iemand gebruikt een vergrendelde bedrijfscomputer. Sommige mensen begrijpen niet waarom de browser een passkey voorstelt. Iemand verliest de toegang tot zijn apparaat.
77 
78Daarom zou ik niet beginnen met "vanaf vandaag geen wachtwoorden meer voor iedereen". Ik zou zo beginnen:
79 
801. passkey optioneel voor interne gebruikers;
812. suggestie om er een aan te maken na een succesvolle login;
823. accountpagina om passkey te hernoemen en te verwijderen;
834. duidelijke terugval;
845. geleidelijke uitrol in de hoofdlogin.
85 
86De tekst in de interface moet eenvoudig zijn. 'Gebruik het vergrendelingsscherm van uw apparaat' is beter dan 'authenticeren met een inwoner FIDO2-referentie'.
87 
88## Fouten die ik zou vermijden
89 
90Genereer geen uitdagingen bij de cliënt. De uitdaging wordt op de server aangemaakt en hoeft slechts één keer te worden geverifieerd.
91 
92Vertrouw niet alleen op de inlog-ID. U moet de handtekening, uitdaging, herkomst en Relying Party ID verifiëren.
93 
94Verwijder geen fallbacks voordat u een goede herstelstroom heeft. Wachtwoordloos hoeft niet te worden "als je je telefoon kwijtraakt, ben je voor altijd weg".
95 
96Beschouw de passkey niet als een puur frontend-knop. Het verbergen van een knop is geen beveiliging: de echte verificatie vindt plaats aan de serverzijde.
97 
98## Passkey-eerst of passkey-vriendelijk?
99 
100Bij een nieuw product kun je passkey eerst denken. Voor een bestaande app geef ik de voorkeur aan passkey-vriendelijk: voeg passkey toe als aanbevolen methode, meet succes en problemen en verlaag vervolgens rustig het wachtwoordgewicht.
101 
102De ideale migratie wordt niet gevoeld. De gebruiker ontdekt dat inloggen makkelijker gaat, niet dat het bedrijf zijn authenticatieprotocol heeft gewijzigd.
103 
104## Conclusie
105 
106De passkey zijn interessant omdat ze tegelijkertijd de beveiliging en UX verbeteren, wat zeldzaam is. Ze zijn geen toverstaf: herstel, compatibiliteit, ondersteuning en uitrol moeten nog goed worden ontworpen.
107 
108Maar de fundamentele verandering is sterk. Vraag gebruikers niet langer om geheimen te verzinnen en te beschermen. U laat het apparaat een cryptografisch bewijs ondertekenen dat aan uw domein is gekoppeld. Minder menselijk geheugen, minder phishing, minder wachtwoordresets. Ik zou zeggen dat ze de moeite waard zijn om serieus te nemen.
109 
110## Bronnen
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 en WebAuthn: inloggen zonder wachtwoord, zonder magielines 1-116 (END) — press q to close

2Wachtwoorden zijn een van die dingen die we hebben genormaliseerd, alleen maar omdat we er al jaren mee leven. Gebruikers vergeten ze, hergebruiken ze, schrijven ze waar ze niet mogen. Teams moeten resets, beleid, hashes, lekken, phishing en ondersteuning beheren.

4De passkey maken de authenticatie niet perfect, maar ze nemen een groot probleem weg: de server hoeft niet langer een geheim te bewaren dat met de gebruiker wordt gedeeld.

6## Wat er echt gebeurt

8Een passkey is een referentie gebaseerd op WebAuthn. Wanneer de gebruiker het aanmaakt, genereert het apparaat een sleutelpaar:

10- een privésleutel, die op het apparaat of in de wachtwoordbeheerder blijft staan;

11- een publieke sleutel, die de server kan opslaan.

13Bij het inloggen vraagt de server niet "vertel mij het wachtwoord". Stuur een willekeurige uitdaging. Het apparaat ondertekent het met de privésleutel. De server verifieert de handtekening met de publieke sleutel.

15Dat is het leuke: als de database wordt gestolen, zijn er geen wachtwoorden meer om te kraken. En als een gebruiker op een nepdomein terechtkomt, is de passkey niet geldig voor dat domein. Het is niet alleen gemak, het is concrete bescherming tegen phishing.

17## De browser fungeert als een brug

19In de browser zijn de twee belangrijkste API:

21- `navigator.credentials.create()` om een passkey te maken;

22- `navigator.credentials.get()` om het te gebruiken tijdens het inloggen.

24Maar de belangrijke logica zit op de server. De server moet de uitdaging genereren, deze tijdelijk opslaan, het antwoord verifiëren, de bron en Relying Party ID controleren en vervolgens de sessie creëren.

26Het klantgedeelte zou bijna saai moeten zijn:

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```

42Als u merkt dat u WebAuthn-codering handmatig implementeert, stop dan. Gebruik een robuuste server-side bibliotheek. De fouten hier zijn geen "schattige bugs", het zijn authenticatiegaten.

44## Wat u in de database moet opslaan

46Het is niet nodig om de halve wereld te redden. Meestal genoeg:

48- ID van de identificatie;

49- publieke sleutel;

50- aangesloten gebruiker;

51- eventuele verificatieteller of metadata;

52- transporten, indien nuttig voor de UX;

53- naam gekozen door de gebruiker;

54- aanmaakdatum en laatste gebruik.

56Een minimale tabel zou er als volgt uit kunnen zien:

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```

70Vervolgens zou ik auditlogboeken en meldingen toevoegen: als iemand een nieuwe passkey op mijn account aanmaakt, wil ik daarvan op de hoogte zijn.

72## UX is belangrijker dan demo

74De demo van een passkey is altijd mooi: je klikt, Face ID, je doet mee. Het eigenlijke product is ingewikkelder.

76Iemand verandert van telefoon. Iemand gebruikt een vergrendelde bedrijfscomputer. Sommige mensen begrijpen niet waarom de browser een passkey voorstelt. Iemand verliest de toegang tot zijn apparaat.

78Daarom zou ik niet beginnen met "vanaf vandaag geen wachtwoorden meer voor iedereen". Ik zou zo beginnen:

801. passkey optioneel voor interne gebruikers;

812. suggestie om er een aan te maken na een succesvolle login;

823. accountpagina om passkey te hernoemen en te verwijderen;

834. duidelijke terugval;

845. geleidelijke uitrol in de hoofdlogin.

86De tekst in de interface moet eenvoudig zijn. 'Gebruik het vergrendelingsscherm van uw apparaat' is beter dan 'authenticeren met een inwoner FIDO2-referentie'.

88## Fouten die ik zou vermijden

90Genereer geen uitdagingen bij de cliënt. De uitdaging wordt op de server aangemaakt en hoeft slechts één keer te worden geverifieerd.

92Vertrouw niet alleen op de inlog-ID. U moet de handtekening, uitdaging, herkomst en Relying Party ID verifiëren.

94Verwijder geen fallbacks voordat u een goede herstelstroom heeft. Wachtwoordloos hoeft niet te worden "als je je telefoon kwijtraakt, ben je voor altijd weg".

96Beschouw de passkey niet als een puur frontend-knop. Het verbergen van een knop is geen beveiliging: de echte verificatie vindt plaats aan de serverzijde.

98## Passkey-eerst of passkey-vriendelijk?

100Bij een nieuw product kun je passkey eerst denken. Voor een bestaande app geef ik de voorkeur aan passkey-vriendelijk: voeg passkey toe als aanbevolen methode, meet succes en problemen en verlaag vervolgens rustig het wachtwoordgewicht.

101

102De ideale migratie wordt niet gevoeld. De gebruiker ontdekt dat inloggen makkelijker gaat, niet dat het bedrijf zijn authenticatieprotocol heeft gewijzigd.

103

104## Conclusie

105

106De passkey zijn interessant omdat ze tegelijkertijd de beveiliging en UX verbeteren, wat zeldzaam is. Ze zijn geen toverstaf: herstel, compatibiliteit, ondersteuning en uitrol moeten nog goed worden ontworpen.

107

108Maar de fundamentele verandering is sterk. Vraag gebruikers niet langer om geheimen te verzinnen en te beschermen. U laat het apparaat een cryptografisch bewijs ondertekenen dat aan uw domein is gekoppeld. Minder menselijk geheugen, minder phishing, minder wachtwoordresets. Ik zou zeggen dat ze de moeite waard zijn om serieus te nemen.

109

110## Bronnen

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