{"id":109,"date":"2026-06-17T20:40:59","date_gmt":"2026-06-17T20:40:59","guid":{"rendered":"https:\/\/shattered.io\/dk\/2026\/06\/17\/webauthn-nodejs-passkeys\/"},"modified":"2026-06-17T20:42:54","modified_gmt":"2026-06-17T20:42:54","slug":"webauthn-nodejs-passkeys","status":"publish","type":"post","link":"https:\/\/shattered.io\/dk\/webauthn-nodejs-passkeys\/","title":{"rendered":"WebAuthn i Node.js: Passwordless login i 12 trin [2026]"},"content":{"rendered":"\n

Adgangskoder er det svageste led i moderne webapplikationers sikkerhed. Phishing-angreb, credential stuffing og datal\u00e6k koster virksomheder og brugere milliarder hvert \u00e5r, og svaret er ikke st\u00e6rkere adgangskoder. Det er ingen<\/strong> adgangskoder. WebAuthn (Web Authentication)<\/strong> er W3C-standarden for passwordless login via offentlig-n\u00f8gle-kryptografi, og den er allerede underst\u00f8ttet af Chrome, Safari, Firefox og Edge p\u00e5 alle platforme. I denne tutorial bygger du en komplet WebAuthn-implementering i Node.js med Express og biblioteket SimpleWebAuthn p\u00e5 under 30 minutter.<\/p>\n\n\n\n

Hvad er WebAuthn og FIDO2?<\/h2>\n\n\n\n

WebAuthn er en webstandard publiceret af W3C i 2019 og opdateret til version 3 i 2025. Den definerer, hvordan en webapplikation kan autentificere en bruger via en kryptografisk authenticator i stedet for en adgangskode. FIDO2<\/strong> er den samlede betegnelse for WebAuthn plus CTAP (Client to Authenticator Protocol), som er den protokol, der forbinder browseren med den fysiske authenticator. WebAuthn er i dag underst\u00f8ttet i alle fire store browsere (Chrome, Edge, Firefox, Safari) og er inkorporeret i alle mobile operativsystemer fra iOS 16+ og Android 9+.<\/p>\n\n\n\n

Hele sikkerhedsmodellen bygger p\u00e5 asymmetrisk kryptografi. Ved registrering genererer authenticatoren et n\u00f8glepar: den private n\u00f8gle forbliver sikkert gemt p\u00e5 brugerens enhed (fx i en TPM-chip, Secure Enclave eller hardware-sikkerhedsn\u00f8gle), mens den offentlige n\u00f8gle sendes til serveren og gemmes i din database. Ved login sender serveren en tilf\u00e6ldig challenge<\/strong>, authenticatoren signerer den med den private n\u00f8gle, og serveren verificerer signaturen med den gemte offentlige n\u00f8gle. Den private n\u00f8gle forlader aldrig enheden.<\/p>\n\n\n\n

Dette design giver tre kritiske sikkerhedsegenskaber. For det f\u00f8rste er passkeys phishing-resistente<\/strong>: credentials er bundet til rpID<\/strong> (Relying Party ID), som svarer til dit dom\u00e6ne. En credential oprettet til app.example.com<\/code> kan ikke bruges p\u00e5 en falsk phishing-side som app-example.com<\/code>. For det andet er der ingen delte hemmeligheder<\/strong>: der er ingen adgangskode at stj\u00e6le fra serverdatabasen, da kun den offentlige n\u00f8gle gemmes. For det tredje er der ingen replay-angreb<\/strong>: hvert login bruger en unik challenge, s\u00e5 en aflyttet response er ubrugelig for en angriber.<\/p>\n\n\n\n

FIDO Alliance, brancheorganisationen bag FIDO2-standarden, har samlet et bredt \u00f8kosystem af implementeringer fra Apple (iCloud Keychain med Face ID og Touch ID), Google (Google Password Manager) og Microsoft (Windows Hello). En passkey oprettet p\u00e5 \u00e9n enhed kan synkroniseres sikkert til andre enheder via skybaserede keychains, hvilket l\u00f8ser det historiske problem med at miste adgang ved enhedsskift. FIDO Alliance rapporterer, at over 15 milliarder onlinekonti i 2025 underst\u00f8tter passkeys som login-metode.<\/p>\n\n\n\n

I Node.js er det mest udbredte bibliotek til WebAuthn-implementering SimpleWebAuthn<\/strong>, et TypeScript-first open source-projekt, der abstraherer kompleksiteten i WebAuthn-protokollen til enkle API-kald. Det deles i to npm-pakker: @simplewebauthn\/server<\/code> til server-side logik og @simplewebauthn\/browser<\/code> til browser-side logik.<\/p>\n\n\n\n

Foruds\u00e6tninger og krav<\/h2>\n\n\n\n

S\u00f8rg for at have f\u00f8lgende installeret og klar, inden du begynder. WebAuthn kr\u00e6ver HTTPS i produktion, men fungerer p\u00e5 localhost<\/code> under udvikling uden certifikat.<\/p>\n\n\n\n

Krav<\/th>Minimum<\/th>Anbefalet<\/th>Bem\u00e6rkning<\/th><\/tr><\/thead>
Node.js<\/td>18.x LTS<\/td>20.x LTS<\/td>SimpleWebAuthn bruger Web Crypto API, kr\u00e6ver Node 18+<\/td><\/tr>
npm<\/td>8.x<\/td>10.x<\/td>Inkluderet med Node.js<\/td><\/tr>
@simplewebauthn\/server<\/td>9.x<\/td>Seneste<\/td>Server-side WebAuthn logik<\/td><\/tr>
@simplewebauthn\/browser<\/td>9.x<\/td>Seneste<\/td>Browser-side WebAuthn logik<\/td><\/tr>
express<\/td>4.18<\/td>4.21+<\/td>HTTP-framework<\/td><\/tr>
express-session<\/td>1.17<\/td>Seneste<\/td>Challenge-lagring i session<\/td><\/tr>
dotenv<\/td>16.x<\/td>Seneste<\/td>Milj\u00f8variabler<\/td><\/tr>
Browser<\/td>Chrome 67+<\/td>Chrome\/Safari\/Edge 2025<\/td>Alle moderne browsere underst\u00f8tter WebAuthn<\/td><\/tr>
HTTPS\/TLS<\/td>Localhost OK<\/td>Certbot + Let’s Encrypt<\/td>P\u00e5kr\u00e6vet i produktion<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Du beh\u00f8ver ikke en fysisk sikkerhedsn\u00f8gle under udvikling. Alle moderne smartphones, computere og tablets har en built-in platform-authenticator: Touch ID og Face ID p\u00e5 Apple-enheder, Windows Hello p\u00e5 Windows-computere, og Android-biometri p\u00e5 Android-enheder. Din udviklingscomputer fungerer som authenticator fra dag \u00e9t, forudsat at du har en biometrisk l\u00e6ser eller PIN-kode konfigureret.<\/p>\n\n\n\n

Kontroller din Node.js-version med node --version<\/code> inden du starter. SimpleWebAuthn bruger Web Crypto API, der er tilg\u00e6ngeligt i Node.js 18+ som en del af standardbiblioteket. Node.js 16 og \u00e6ldre kr\u00e6ver en polyfill og anbefales ikke til nye projekter.<\/p>\n\n\n\n

WebAuthn-protokollen i praksis: de to ceremonies<\/h2>\n\n\n\n

Inden du skriver kode, er det vigtigt at forst\u00e5 de to forl\u00f8b, WebAuthn definerer. Protokollen kalder dem registration ceremony<\/strong> og authentication ceremony<\/strong>. Hvert forl\u00f8b er en tovejs-kommunikation med en tilf\u00e6ldig challenge i midten, der sikrer, at svaret aldrig kan genbruges.<\/p>\n\n\n\n

Under registration ceremony<\/strong> sker f\u00f8lgende seks trin: Serveren genererer en tilf\u00e6ldig challenge og sender den til browseren med metadata om din app. Browseren videresender til platform-authenticatoren (fx Touch ID). Authenticatoren genererer et n\u00f8glepar og returnerer en signeret attestation, der indeholder den offentlige n\u00f8gle. Browseren sender attestationen til serveren. Serveren verificerer challenge og signatur. Serveren gemmer den offentlige n\u00f8gle, credential ID og en startt\u00e6ller i databasen.<\/p>\n\n\n\n

Under authentication ceremony<\/strong> sker f\u00f8lgende fem trin: Serveren genererer en ny tilf\u00e6ldig challenge. Browseren sender den til authenticatoren, som signerer den med den private n\u00f8gle. Den signerede assertion sendes til serveren. Serveren verificerer signaturen med den gemte offentlige n\u00f8gle. Serveren kontrollerer at t\u00e6lleren er steget (clone-detection) og logger brugeren ind.<\/p>\n\n\n\n

T\u00e6lleren er en s\u00e6rlig sikkerhedsmekanisme: hver gang en credential bruges, \u00f8ges en intern t\u00e6ller p\u00e5 authenticatoren. Serveren gemmer den seneste v\u00e6rdi og kontrollerer, at den nye t\u00e6llerv\u00e6rdi er h\u00f8jere end den gemte. Hvis en angriber kopierer en credential og fors\u00f8ger at bruge den, vil t\u00e6llerv\u00e6rdien ikke stemme, og serveren afviser fors\u00f8get. Platform-authenticatorer med sky-synkronisering s\u00e6tter ofte t\u00e6ller til 0, men logikken forbliver vigtig at implementere.<\/p>\n\n\n\n

Trin 1-3: Projektops\u00e6tning og installation<\/h2>\n\n\n\n

Start med at oprette et nyt Node.js-projekt og installere de n\u00f8dvendige pakker. Du har brug for tre server-side pakker. I dette projekt serverer vi en simpel frontend direkte fra Express for at holde ops\u00e6tningen fokuseret p\u00e5 WebAuthn-logikken.<\/p>\n\n\n\n

# Trin 1: Opret projektmappe og initialiser npm\nmkdir webauthn-nodejs && cd webauthn-nodejs\nnpm init -y\n\n# Trin 2: Installer server-side pakker\nnpm install express express-session @simplewebauthn\/server dotenv\n\n# Trin 3: Installer udviklingsafh\u00e6ngigheder\nnpm install --save-dev nodemon\n\n# Forventet output efter installation:\n# added 42 packages, and audited 43 packages in 4s\n# found 0 vulnerabilities\n\n# Projektstruktur:\n# webauthn-nodejs\/\n# \u251c\u2500\u2500 server.js          (Express server og API-endpoints)\n# \u251c\u2500\u2500 public\/\n# \u2502   \u251c\u2500\u2500 index.html     (Login\/registrerings-UI)\n# \u2502   \u2514\u2500\u2500 auth.js        (Frontend WebAuthn-logik)\n# \u2514\u2500\u2500 .env               (Milj\u00f8variabler - aldrig i git)<\/code><\/pre>\n\n\n\n
Opret en .env<\/code>-fil med dine milj\u00f8variabler. I produktion skal du \u00e6ndre alle tre v\u00e6rdier til dit faktiske dom\u00e6ne og en st\u00e6rk, tilf\u00e6ldig session-hemmelighed genereret med node -e \"console.log(require('crypto').randomBytes(32).toString('hex'))\"<\/code>.<\/p>\n\n\n\n
# .env (tilf\u00f8j til .gitignore straks)\nSESSION_SECRET=erstat-med-64-hexadecimale-tegn-fra-crypto-randomBytes\nRP_ID=localhost\nRP_NAME=Min WebAuthn App\nORIGIN=http:\/\/localhost:3000\nPORT=3000\nNODE_ENV=development<\/code><\/pre>\n\n\n\n
Tilf\u00f8j start-scripts i package.json<\/code> og opret en .gitignore<\/code>-fil med det samme. .env<\/code> i versionskontrol er en af de mest udbredte \u00e5rsager til credential-l\u00e6kage i open source-projekter.<\/p>\n\n\n\n
Trin 4-5: Express-server og relying party-konfiguration<\/h2>\n\n\n\n
Nu opretter du selve Express-serveren. Det vigtigste konfigurationspunkt er rpID<\/strong> og origin<\/strong>. rpID<\/code> er dom\u00e6net for din app, eksklusive protokol og port. I produktion vil det typisk v\u00e6re example.com<\/code> eller app.example.com<\/code>. origin<\/code> er den fulde URL inkl. protokol og port, som browseren bruger. Disse to v\u00e6rdier skal matche pr\u00e6cist, og WebAuthn afviser alle requests med mismatch.<\/p>\n\n\n\n
\/\/ server.js\nrequire('dotenv').config();\nconst express = require('express');\nconst session = require('express-session');\nconst crypto = require('crypto');\nconst {\n  generateRegistrationOptions,\n  verifyRegistrationResponse,\n  generateAuthenticationOptions,\n  verifyAuthenticationResponse,\n} = require('@simplewebauthn\/server');\n\nconst app = express();\n\n\/\/ Relying Party-konfiguration (rpID = dom\u00e6ne uden protokol og port)\nconst rpName = process.env.RP_NAME || 'Min App';\nconst rpID   = process.env.RP_ID   || 'localhost';\nconst origin = process.env.ORIGIN  || 'http:\/\/localhost:3000';\n\n\/\/ Middleware\napp.use(express.json());\napp.use(express.static('public'));\napp.use(session({\n  secret: process.env.SESSION_SECRET,\n  resave: false,\n  saveUninitialized: false,\n  cookie: {\n    secure:   process.env.NODE_ENV === 'production', \/\/ true = kun HTTPS\n    httpOnly: true,    \/\/ Ingen JavaScript-adgang til cookie\n    sameSite: 'lax',   \/\/ CSRF-beskyttelse\n    maxAge:   10 * 60 * 1000, \/\/ 10 minutter til registrering\/login\n  },\n}));\n\n\/\/ In-memory brugerstore (udskift med database i produktion)\n\/\/ Struktur: username -> { id: Buffer, username: string, credentials: Array }\nconst users = new Map();\n\nconst PORT = process.env.PORT || 3000;\napp.listen(PORT, () => {\n  console.log(`WebAuthn server k\u00f8rer p\u00e5 port ${PORT}`);\n  console.log(`rpID: ${rpID} | origin: ${origin}`);\n});<\/code><\/pre>\n\n\n\n
Lagringen med Map()<\/code> er kun beregnet til demonstration. I en produktionsapp gemmer du brugere og credentials i en database. Credentials-tabellen skal som minimum indeholde: credentialID<\/code>, credentialPublicKey<\/code>, counter<\/code>, userId<\/code> og transports<\/code>. Overvej at oprette en separat tabel for credentials med en fremmed n\u00f8gle til brugertabellen, da \u00e9n bruger kan have flere registrerede enheder (telefon, laptop, hardware-n\u00f8gle).<\/p>\n\n\n\n
Trin 6: Registration options-endpoint<\/h2>\n\n\n\n
Det f\u00f8rste API-endpoint genererer WebAuthn-options til registrering. Serveren opretter en kryptografisk challenge og sender options til browseren, der videresender til authenticatoren. authenticatorAttachment: 'platform'<\/code> beder specifikt om en built-in authenticator (Touch ID, Face ID, Windows Hello). Skift til 'cross-platform'<\/code> for hardware-n\u00f8gler som YubiKey, eller udelad parameteren for at tillade begge typer.<\/p>\n\n\n\n
\/\/ POST \/auth\/register\/options\napp.post('\/auth\/register\/options', async (req, res) => {\n  const { username } = req.body;\n\n  if (!username || username.trim().length < 3) {\n    return res.status(400).json({ error: 'Brugernavn skal v\u00e6re mindst 3 tegn' });\n  }\n\n  const cleanUsername = username.trim().toLowerCase();\n\n  \/\/ Opret bruger hvis den ikke eksisterer\n  if (!users.has(cleanUsername)) {\n    users.set(cleanUsername, {\n      id: crypto.randomUUID(), \/\/ Unikt bruger-ID (gem i database med auto-increment)\n      username: cleanUsername,\n      credentials: [],\n    });\n  }\n\n  const user = users.get(cleanUsername);\n\n  const options = await generateRegistrationOptions({\n    rpName,\n    rpID,\n    userID:          Buffer.from(user.id),\n    userName:        user.username,\n    userDisplayName: user.username,\n    timeout:         60000,         \/\/ 60 sekunders timeout for brugerinteraktion\n    attestationType: 'none',        \/\/ 'none' kr\u00e6ver ingen producentbevis\n    authenticatorSelection: {\n      authenticatorAttachment: 'platform',    \/\/ built-in enhed\n      userVerification:        'preferred',   \/\/ brug biometri hvis muligt\n      residentKey:             'preferred',   \/\/ gem credential p\u00e5 enheden (passkey)\n    },\n    excludeCredentials: user.credentials.map(cred => ({\n      id:         cred.credentialID,\n      type:       'public-key',\n      transports: cred.transports || [],\n    })),\n  });\n\n  \/\/ Gem challenge i session til verifikation (ALDRIG client-side)\n  req.session.currentChallenge      = options.challenge;\n  req.session.registrationUsername  = cleanUsername;\n\n  res.json(options);\n});<\/code><\/pre>\n\n\n\n
excludeCredentials<\/code> er en vigtig parameter. Den fort\u00e6ller authenticatoren, hvilke credentials brugeren allerede har registreret p\u00e5 dette site. Hvis brugeren fors\u00f8ger at registrere den samme enhed to gange, afviser browseren fors\u00f8get automatisk med en InvalidStateError<\/code>. attestationType: 'none'<\/code> er det rigtige valg for de fleste webapplikationer: det kr\u00e6ver ikke, at authenticatoren beviser sin oprindelse hos producenten via FIDO Metadata Service, og det giver den bedste browserkompatibilitet.<\/p>\n\n\n\n
Trin 7: Verificer og gem registration-response<\/h2>\n\n\n\n
Browseren sender authenticatorens svar tilbage til dette endpoint. Her verificerer serveren challenge, origin og rpID mod svaret og gemmer den offentlige n\u00f8gle i databasen. Husk altid at slette challenge fra session efter verifikation, hvad enten det lykkes eller ej. En genbrugt challenge er en sikkerhedsbrist.<\/p>\n\n\n\n
\/\/ POST \/auth\/register\/verify\napp.post('\/auth\/register\/verify', async (req, res) => {\n  const body              = req.body;\n  const username          = req.session.registrationUsername;\n  const expectedChallenge = req.session.currentChallenge;\n\n  \/\/ Ryd challenge fra session - engangsbrug uanset outcome\n  req.session.currentChallenge     = undefined;\n  req.session.registrationUsername = undefined;\n\n  if (!username || !expectedChallenge) {\n    return res.status(400).json({ error: 'Session udl\u00f8bet eller ugyldig' });\n  }\n\n  const user = users.get(username);\n  if (!user) {\n    return res.status(400).json({ error: 'Bruger ikke fundet' });\n  }\n\n  let verification;\n  try {\n    verification = await verifyRegistrationResponse({\n      response:          body,\n      expectedChallenge,\n      expectedOrigin:    origin,\n      expectedRPID:      rpID,\n    });\n  } catch (err) {\n    console.error('Registration verification fejlede:', err.message);\n    return res.status(400).json({ error: err.message });\n  }\n\n  const { verified, registrationInfo } = verification;\n\n  if (verified && registrationInfo) {\n    const { credential, credentialDeviceType, credentialBackedUp } = registrationInfo;\n\n    \/\/ Gem credential i brugerens credentials-array (brug database i produktion)\n    user.credentials.push({\n      credentialID:        credential.id,\n      credentialPublicKey: credential.publicKey,\n      counter:             credential.counter,\n      credentialDeviceType,\n      credentialBackedUp,   \/\/ true = passkey synkroniseret via sky\n      transports:           body.response.transports || [],\n      createdAt:            new Date().toISOString(),\n    });\n\n    console.log(`Registrering OK: ${username} | backed up: ${credentialBackedUp}`);\n    return res.json({ verified: true });\n  }\n\n  res.status(400).json({ verified: false, error: 'Verifikation mislykkedes' });\n});<\/code><\/pre>\n\n\n\n
credentialBackedUp<\/code> er en egenskab fra WebAuthn Level 3-specifikationen. Den fort\u00e6ller, om passkey’en er synkroniseret til skyen (fx iCloud Keychain eller Google Password Manager). En synkroniseret passkey er ikke bundet til \u00e9n enhed og giver brugeren mere fleksibilitet. Din app kan vise en advarsel til brugere, der kun har \u00e9n ikke-synkroniseret credential, og bede dem om at registrere en backup-enhed.<\/p>\n\n\n\n
Trin 8-9: Authentication options og login-endpoint<\/h2>\n\n\n\n
Authentication-flowet ligner registration, men authenticatoren signerer blot en ny challenge med den allerede oprettede private n\u00f8gle. Serveren angiver, hvilke credentials den accepterer via allowCredentials<\/code>-listen. Hvis listen er tom, tillader WebAuthn enhver credential gemt for dette rpID p\u00e5 enheden, hvilket muligg\u00f8r “conditional UI” (passkey-autofill-lignende flow uden at kende brugernavnet p\u00e5 forh\u00e5nd).<\/p>\n\n\n\n
\/\/ POST \/auth\/login\/options\napp.post('\/auth\/login\/options', async (req, res) => {\n  const { username } = req.body;\n  const cleanUsername = (username || '').trim().toLowerCase();\n  const user = users.get(cleanUsername);\n\n  if (!user || user.credentials.length === 0) {\n    return res.status(404).json({ error: 'Bruger ikke fundet eller ingen passkeys registreret' });\n  }\n\n  const options = await generateAuthenticationOptions({\n    rpID,\n    timeout:          60000,\n    allowCredentials: user.credentials.map(cred => ({\n      id:         cred.credentialID,\n      type:       'public-key',\n      transports: cred.transports,\n    })),\n    userVerification: 'preferred',\n  });\n\n  req.session.currentChallenge = options.challenge;\n  req.session.loginUsername    = cleanUsername;\n\n  res.json(options);\n});\n\n\/\/ POST \/auth\/login\/verify\napp.post('\/auth\/login\/verify', async (req, res) => {\n  const body              = req.body;\n  const username          = req.session.loginUsername;\n  const expectedChallenge = req.session.currentChallenge;\n\n  req.session.currentChallenge = undefined;\n  req.session.loginUsername    = undefined;\n\n  if (!username || !expectedChallenge) {\n    return res.status(400).json({ error: 'Session ugyldig eller udl\u00f8bet' });\n  }\n\n  const user = users.get(username);\n  if (!user) {\n    return res.status(400).json({ error: 'Bruger ikke fundet' });\n  }\n\n  \/\/ Find matchende credential baseret p\u00e5 credentialID fra browser-response\n  const credential = user.credentials.find(c => c.credentialID === body.id);\n  if (!credential) {\n    return res.status(400).json({ error: 'Credential ikke fundet for denne bruger' });\n  }\n\n  let verification;\n  try {\n    verification = await verifyAuthenticationResponse({\n      response:          body,\n      expectedChallenge,\n      expectedOrigin:    origin,\n      expectedRPID:      rpID,\n      credential: {\n        id:        credential.credentialID,\n        publicKey: credential.credentialPublicKey,\n        counter:   credential.counter,\n      },\n    });\n  } catch (err) {\n    console.error('Authentication verification fejlede:', err.message);\n    return res.status(400).json({ error: err.message });\n  }\n\n  const { verified, authenticationInfo } = verification;\n\n  if (verified) {\n    \/\/ Opdater counter efter hvert succesfuldt login (forhindrer replay-angreb)\n    credential.counter = authenticationInfo.newCounter;\n\n    \/\/ Opret bruger-session\n    req.session.userId              = username;\n    req.session.cookie.maxAge       = 7 * 24 * 60 * 60 * 1000; \/\/ 7 dage\n\n    console.log(`Login OK: ${username} | ny counter: ${authenticationInfo.newCounter}`);\n    return res.json({ verified: true });\n  }\n\n  res.status(400).json({ verified: false, error: 'Autentificering mislykkedes' });\n});<\/code><\/pre>\n\n\n\n
Trin 10-11: Frontend-kode med @simplewebauthn\/browser<\/h2>\n\n\n\n
Frontend-koden bruger @simplewebauthn\/browser<\/code> til at h\u00e5ndtere interaktionen med browseren. Biblioteket eksponerer to n\u00f8glefunktioner: startRegistration()<\/code> og startAuthentication()<\/code>. Disse funktioner kalder Web Authentication API internt og returnerer base64url-kodede responses, som serveren forventer. Du kan indl\u00e6se biblioteket direkte fra CDN til simple projekter.<\/p>\n\n\n\n
\/\/ public\/auth.js\nimport {\n  startRegistration,\n  startAuthentication,\n} from 'https:\/\/cdn.jsdelivr.net\/npm\/@simplewebauthn\/browser@latest\/dist\/bundle\/index.esm.js';\n\n\/\/ Registrer en ny passkey\nasync function registerPasskey() {\n  const username = document.getElementById('username').value.trim();\n  if (!username) return showStatus('Indtast et brugernavn');\n\n  try {\n    \/\/ Hent options fra server (inkl. challenge)\n    const optionsRes = await fetch('\/auth\/register\/options', {\n      method:  'POST',\n      headers: { 'Content-Type': 'application\/json' },\n      body:    JSON.stringify({ username }),\n    });\n\n    if (!optionsRes.ok) {\n      const err = await optionsRes.json();\n      return showStatus('Fejl: ' + err.error);\n    }\n\n    const options = await optionsRes.json();\n\n    \/\/ Aktiverer Touch ID \/ Face ID \/ Windows Hello-dialog i browseren\n    const attestation = await startRegistration(options);\n\n    \/\/ Send authenticator-response til server til verifikation\n    const verifyRes = await fetch('\/auth\/register\/verify', {\n      method:  'POST',\n      headers: { 'Content-Type': 'application\/json' },\n      body:    JSON.stringify(attestation),\n    });\n    const result = await verifyRes.json();\n\n    if (result.verified) {\n      showStatus('Passkey registreret! Du kan nu logge ind.');\n    } else {\n      showStatus('Registrering fejlede: ' + (result.error || 'Ukendt fejl'));\n    }\n  } catch (err) {\n    \/\/ Brugeren annullerede, timeout, eller browser underst\u00f8tter ikke WebAuthn\n    if (err.name === 'NotAllowedError') {\n      showStatus('Annulleret af bruger eller timeout.');\n    } else {\n      showStatus('Fejl: ' + err.message);\n    }\n  }\n}\n\n\/\/ Log ind med passkey\nasync function loginWithPasskey() {\n  const username = document.getElementById('username').value.trim();\n  if (!username) return showStatus('Indtast dit brugernavn');\n\n  try {\n    const optionsRes = await fetch('\/auth\/login\/options', {\n      method:  'POST',\n      headers: { 'Content-Type': 'application\/json' },\n      body:    JSON.stringify({ username }),\n    });\n\n    if (!optionsRes.ok) {\n      const err = await optionsRes.json();\n      return showStatus('Fejl: ' + err.error);\n    }\n\n    const options       = await optionsRes.json();\n    const assertion     = await startAuthentication(options);\n\n    const verifyRes = await fetch('\/auth\/login\/verify', {\n      method:  'POST',\n      headers: { 'Content-Type': 'application\/json' },\n      body:    JSON.stringify(assertion),\n    });\n    const result = await verifyRes.json();\n\n    if (result.verified) {\n      window.location.href = '\/dashboard';\n    } else {\n      showStatus('Login fejlede: ' + (result.error || 'Ukendt fejl'));\n    }\n  } catch (err) {\n    showStatus('Fejl: ' + err.message);\n  }\n}\n\nfunction showStatus(msg) {\n  document.getElementById('status').textContent = msg;\n}\n\ndocument.getElementById('btn-register').addEventListener('click', registerPasskey);\ndocument.getElementById('btn-login').addEventListener('click', loginWithPasskey);<\/code><\/pre>\n\n\n\n
Trin 12: Beskyt routes, logout og credential-administration<\/h2>\n\n\n\n
Med en fungerende WebAuthn-implementation har du brug for at beskytte dine applikationsroutes og implementere en ordentlig logout-funktion. En simpel middleware-funktion tjekker, om brugeren har en aktiv session, og returnerer en 401-fejl ellers.<\/p>\n\n\n\n
\/\/ Autentificerings-middleware\nfunction requireAuth(req, res, next) {\n  if (req.session.userId) return next();\n  res.status(401).json({ error: 'Kr\u00e6ver login' });\n}\n\n\/\/ Beskyttet profil-API\napp.get('\/api\/profile', requireAuth, (req, res) => {\n  const user = users.get(req.session.userId);\n  res.json({\n    username:        user.username,\n    credentialCount: user.credentials.length,\n    credentials:     user.credentials.map(cred => ({\n      id:        cred.credentialID.substring(0, 16) + '...',\n      backedUp:  cred.credentialBackedUp,\n      transports: cred.transports,\n      createdAt: cred.createdAt,\n    })),\n  });\n});\n\n\/\/ Logout - \u00f8del\u00e6g server-side session\napp.post('\/auth\/logout', (req, res) => {\n  req.session.destroy(err => {\n    if (err) return res.status(500).json({ error: 'Logout fejlede' });\n    res.clearCookie('connect.sid');\n    res.json({ success: true });\n  });\n});\n\n\/\/ Slet en specifik passkey (credential-administration)\napp.delete('\/auth\/credential\/:credentialId', requireAuth, (req, res) => {\n  const user   = users.get(req.session.userId);\n  const before = user.credentials.length;\n\n  user.credentials = user.credentials.filter(\n    c => c.credentialID !== req.params.credentialId\n  );\n\n  if (user.credentials.length === before) {\n    return res.status(404).json({ error: 'Credential ikke fundet' });\n  }\n\n  res.json({ deleted: true, remaining: user.credentials.length });\n});<\/code><\/pre>\n\n\n\n
Tilbyd altid brugere mulighed for at se og slette deres registrerede passkeys. En bruger kan have registreret 3-4 enheder over tid, og det er god praksis at give dem kontrol over, hvilke enheder der har adgang. Vis transports<\/code>-feltet (['internal']<\/code> for platform-authenticator, ['usb']<\/code> for YubiKey) og credentialBackedUp<\/code>-status, s\u00e5 brugerne ved, hvilke enheder der er synkroniseret til skyen.<\/p>\n\n\n\n
Til produktion<\/strong> skal du erstatte den in-memory session-store med Redis via connect-redis<\/code>, da den in-memory store nulstilles ved servergenstart og ikke skalerer til flere Node.js-instanser. Se vores guide til sikker session-styring i Node.js<\/a> for komplet Redis-ops\u00e6tning og session-hardening.<\/p>\n\n\n\n
WebAuthn vs traditionel adgangskode: sikkerhedssammenligning<\/h2>\n\n\n\n
En direkte sammenligning viser, at WebAuthn adresserer alle de vigtigste angrebsvektorer mod adgangskodebaserede systemer. Nedenst\u00e5ende tabel opsummerer de centrale sikkerhedsegenskaber ved begge tilgange, plus TOTP som mellemvej.<\/p>\n\n\n\n
Angrebsvektor<\/th>Adgangskode<\/th>Adgangskode + TOTP<\/th>WebAuthn \/ Passkeys<\/th><\/tr><\/thead>
Phishing<\/td>S\u00e5rbar<\/td>S\u00e5rbar (TOTP kan phishes)<\/td>Immun (rpID-binding)<\/td><\/tr>
Credential stuffing<\/td>S\u00e5rbar<\/td>Reduceret risiko<\/td>Immun (unikke n\u00f8gler per site)<\/td><\/tr>
Database-l\u00e6kage<\/td>S\u00e5rbar (hashes kan crackes)<\/td>S\u00e5rbar<\/td>Immun (kun offentlig n\u00f8gle gemmes)<\/td><\/tr>
Replay-angreb<\/td>S\u00e5rbar<\/td>Reduceret (30s TOTP-vindue)<\/td>Immun (unik challenge pr. login)<\/td><\/tr>
Brute-force<\/td>S\u00e5rbar<\/td>Reduceret<\/td>Immun (privat n\u00f8gle forlader ikke enhed)<\/td><\/tr>
Man-in-the-middle<\/td>S\u00e5rbar p\u00e5 HTTP<\/td>S\u00e5rbar<\/td>Immun (TLS + origin-validering)<\/td><\/tr>
Brugerfrikttion<\/td>Husker\/genbruger kodeord<\/td>Skifter kodeord + TOTP-kode<\/td>Touch\/Face ID, ingen at huske<\/td><\/tr>
Enhedstab-risiko<\/td>Lav (kodeord i hjernen)<\/td>Moderat (backup-koder)<\/td>Lav med sky-synkronisering<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
WebAuthn eliminerer ikke alle sikkerhedsrisici. En kompromitteret enhed giver en angriber adgang til platform-authenticatoren, hvis enheden ikke er beskyttet med PIN, biometri eller enhedskryptering. Ondsindede apps kan i teorien misbruge platform-authenticatoren, men operativsystemerne (iOS, Android, Windows, macOS) implementerer strenge sandboksningsregler, der forhindrer dette. Og account takeover via social engineering (brugeren overbevises til at registrere angriberens enhed) forbliver en vektor, der kr\u00e6ver brugeruddannelse og verificerings-policies.<\/p>\n\n\n\n
5 almindelige faldgruber ved WebAuthn i Node.js<\/h2>\n\n\n\n
De fleste implementeringsfejl med WebAuthn falder i fem kategorier. Alle fem er typiske for udviklere, der implementerer WebAuthn for f\u00f8rste gang.<\/p>\n\n\n\n
Faldgrube 1: Forkert rpID eller origin.<\/strong> Den hyppigste fejl er mismatch mellem rpID<\/code> og origin<\/code>. Hvis din app k\u00f8rer p\u00e5 https:\/\/app.example.com<\/code>, er rpID<\/code> enten app.example.com<\/code> eller for\u00e6ldreDom\u00e6net example.com<\/code>, aldrig https:\/\/app.example.com<\/code>. Og origin<\/code> er altid den fulde URL med protokol: https:\/\/app.example.com<\/code>. Blander du disse, returnerer verifyRegistrationResponse()<\/code> en fejl med besked om “Invalid origin”. Log begge v\u00e6rdier ved opstart og sammenlign med det, browseren sender i clientDataJSON<\/code> (base64url-kodet JSON i response-objektet).<\/p>\n\n\n\n
Faldgrube 2: HTTP i produktion.<\/strong> WebAuthn kr\u00e6ver HTTPS undtagen p\u00e5 localhost<\/code>. Chrome og Firefox afviser stille WebAuthn API-kald p\u00e5 usikrede sider med fejlen “SecurityError: The operation is insecure.” Brugeren ser blot en tom fejlbesked. S\u00e6t altid HTTPS op med Certbot og Nginx, inden du tester WebAuthn p\u00e5 en server. Se vores guide til gratis TLS-certifikat med Certbot<\/a>.<\/p>\n\n\n\n
Faldgrube 3: Challenge gemmes ikke korrekt.<\/strong> Challenge skal gemmes server-side (i session) og sammenlignes med den, der returneres i response. Gem den aldrig client-side og send den ikke tilbage fra klienten som en del af request-body. Mange tutorials gemmer challenge i en global variabel i stedet for i session, hvilket giver fejl ved samtidige requests fra flere brugere.<\/p>\n\n\n\n
Faldgrube 4: Counter-logik springes over.<\/strong> T\u00e6lleren er din prim\u00e6re forsvarslinje mod klonet-credential-angreb. SimpleWebAuthn kaster automatisk en fejl, hvis t\u00e6llerv\u00e6rdien ikke er korrekt, men kun hvis du sender den rigtige credential.counter<\/code> i verifyAuthenticationResponse()<\/code>. Glemmer du at opdatere credential.counter<\/code> i databasen efter hvert succesfuldt login, virker clone-detection ikke.<\/p>\n\n\n\n
Faldgrube 5: Ingen genoprettelsesmekanisme.<\/strong> Hvad sker der, n\u00e5r en bruger mister sin enhed og ikke har registreret andre passkeys? WebAuthn giver ikke automatisk en account recovery-l\u00f8sning. Implementer \u00e9n af disse alternativer fra start: (a) kr\u00e6v at nye brugere registrerer mindst 2 passkeys ved onboarding, (b) tilbyd backup-koder (8 alfanumeriske koder, brug CSPRNG) ved registrering, eller (c) implementer e-mail-baseret kontobekr\u00e6ftelse som fallback. Systemer uden recovery-flow mister brugere, der skifter telefon.<\/p>\n\n\n\n
Fejlretning: 8 typiske fejl og l\u00f8sninger<\/h2>\n\n\n\n
Her er de 8 mest frekvente fejlbeskeder og l\u00f8sninger, n\u00e5r du implementerer WebAuthn i Node.js.<\/p>\n\n\n\n
Fejlbesked<\/th>\u00c5rsag<\/th>L\u00f8sning<\/th><\/tr><\/thead>
Unexpected registration response origin<\/code><\/td>ORIGIN i .env matcher ikke browserens URL<\/td>S\u00e6t ORIGIN=http:\/\/localhost:3000 med korrekt port<\/td><\/tr>
Unexpected rpID<\/code><\/td>rpID indeholder protokol eller port<\/td>RP_ID=localhost (ikke http:\/\/localhost:3000)<\/td><\/tr>
SecurityError: The operation is insecure<\/code><\/td>HTTP bruges i stedet for HTTPS<\/td>Ops\u00e6t TLS med Certbot, eller test kun p\u00e5 localhost<\/td><\/tr>
NotAllowedError: timed out waiting...<\/code><\/td>Brugeren afviste eller 60-sek timeout n\u00e5et<\/td>Informer brugeren om Touch ID-dialogen, \u00f8g timeout til 120000<\/td><\/tr>
InvalidStateError: authenticator already registered<\/code><\/td>Credential allerede registreret (excludeCredentials virker)<\/td>Normalfunktion – informer brugeren om, at enheden er registreret<\/td><\/tr>
session.currentChallenge is undefined<\/code><\/td>Session udl\u00f8bet eller ikke gemt<\/td>\u00d8g session-timeout eller brug Redis til session-store<\/td><\/tr>
Received unexpected authenticator counter<\/code><\/td>Counter i DB er ikke opdateret<\/td>S\u00f8rg for at credential.counter opdateres i DB efter hvert login<\/td><\/tr>
credential.publicKey is not a Uint8Array<\/code><\/td>Forkert serialisering ved lagring i database<\/td>Gem publicKey som Buffer – gendan med Buffer.from(stored, ‘base64’)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Debug-teknik:<\/strong> clientDataJSON<\/code>-feltet i svaret er base64url-kodet JSON med den origin og challenge, browseren brugte. Dekod den server-side med denne linje for at se pr\u00e6cis, hvad browseren sender, og sammenlign med din konfiguration:<\/p>\n\n\n\n
\/\/ Dekod clientDataJSON til debug (k\u00f8r i verify-endpointet)\nconst clientData = JSON.parse(\n  Buffer.from(req.body.response.clientDataJSON, 'base64url').toString()\n);\nconsole.log('Browser sendte:', {\n  type:      clientData.type,      \/\/ 'webauthn.create' eller 'webauthn.get'\n  origin:    clientData.origin,    \/\/ skal matche din ORIGIN\n  challenge: clientData.challenge, \/\/ skal matche session.currentChallenge\n});<\/code><\/pre>\n\n\n\n
Et succesfuldt login-forl\u00f8b giver f\u00f8lgende output i serverlogs:<\/p>\n\n\n\n
# Server-output ved succesfuld registrering:\nWebAuthn server k\u00f8rer p\u00e5 port 3000\nrpID: localhost | origin: http:\/\/localhost:3000\nRegistrering OK: alice | backed up: true\n\n# Server-output ved succesfuldt login:\nLogin OK: alice | ny counter: 1\n\n# Server-output ved tredje login:\nLogin OK: alice | ny counter: 3<\/code><\/pre>\n\n\n\n
Avancerede tips til WebAuthn i produktion<\/h2>\n\n\n\n
Conditional UI (passkey autofill).<\/strong> WebAuthn Level 3 introducerer Conditional Mediation, som lader browseren vise passkeys direkte i brugernavnfeltet via en autocomplete-dropdown. Brugeren beh\u00f8ver ikke klikke en separat “Log ind med passkey”-knap. Det kr\u00e6ver mediation: 'conditional'<\/code> i startAuthentication()<\/code> og autocomplete=\"username webauthn\"<\/code> p\u00e5 input-feltet. Conditional UI er underst\u00f8ttet i Chrome 108+, Safari 16+ og Edge 108+.<\/p>\n\n\n\n
\/\/ Conditional UI: passkey vises i autocomplete-dropdown\n\/\/ Send allowCredentials: [] for at tillade alle credentials til dette rpID\nconst options = await generateAuthenticationOptions({ rpID, allowCredentials: [] });\n\/\/ I auth.js (browser):\nconst assertion = await startAuthentication(options, true); \/\/ true = conditional UI\n\/\/ HTML input:\n\/\/ <input type=\"text\" autocomplete=\"username webauthn\" id=\"username\" \/><\/code><\/pre>\n\n\n\n
Cross-platform authenticatorer (YubiKey).<\/strong> Skift authenticatorAttachment<\/code> til 'cross-platform'<\/code> for at underst\u00f8tte hardware-sikkerhedsn\u00f8gler som YubiKey 5 Series og Google Titan Key. Disse n\u00f8gler er de st\u00e6rkeste authenticatorer, da den private n\u00f8gle sidder i en dedikeret sikkerhedschip, der er tamper-resistant og ikke synkroniseres til skyen. For organisationer med h\u00f8je sikkerhedskrav (banker, myndigheder, kritisk infrastruktur, DORA-regulerede finansvirksomheder) anbefaler FIDO Alliance hardware-sikkerhedsn\u00f8gler frem for platform-authenticatorer.<\/p>\n\n\n\n
Redis til session-skalering.<\/strong> N\u00e5r du k\u00f8rer Node.js i cluster-mode eller bag en load balancer med flere instanser, skal session-data deles p\u00e5 tv\u00e6rs af processer. Installer connect-redis<\/code> og konfigurer express-session<\/code> til at bruge Redis som store. Dette sikrer, at challenge’n gemt p\u00e5 instans A stadig er tilg\u00e6ngelig, n\u00e5r browserens svar lander p\u00e5 instans B. Se vores guide til sikker session i Node.js<\/a> for komplet Redis-konfiguration.<\/p>\n\n\n\n
Rate limiting p\u00e5 auth-endpoints.<\/strong> Selvom WebAuthn er modstandsdygtig over for brute-force p\u00e5 credentials, b\u00f8r du beskytte dine endpoints mod misbrugsfors\u00f8g og DDoS. Tils\u00e6t express-rate-limit<\/code> med en gr\u00e6nse p\u00e5 10 requests per minut per IP p\u00e5 \/auth\/register\/options<\/code> og \/auth\/login\/options<\/code>. Se vores guide til OAuth 2.0 og OpenID Connect i Node.js<\/a> for et komplet eksempel p\u00e5 rate-limiting i auth-flows.<\/p>\n\n\n\n
Attestation til enterprise-brug.<\/strong> attestationType: 'none'<\/code> er korrekt til forbrugerapps. Enterprise-implementeringer kan kr\u00e6ve 'direct'<\/code> attestation, som beviser authenticatorens oprindelse hos en betroet producent via FIDO Metadata Service. Det giver organisationer mulighed for at h\u00e5ndh\u00e6ve, at kun godkendte hardware-modeller bruges, men det reducerer privatlivets beskyttelse og \u00f8ger implementeringskompleksiteten markant. S\u00e6t altid 'none'<\/code>, medmindre du har et specifikt compliance-krav til attestation.<\/p>\n\n\n\n
PostgreSQL-databaseskema og datapersistering<\/h2>\n\n\n\n
I produktion erstatter du Map()<\/code>-lagringen med en relationel database. Her er et komplet PostgreSQL-skema med de felttyper og indekser, som WebAuthn-implementeringen kr\u00e6ver. Skemaet er designet til at underst\u00f8tte multi-enhed per bruger og giver effektive opslag via credential ID.<\/p>\n\n\n\n
-- PostgreSQL-skema til WebAuthn passkeys\n\nCREATE TABLE users (\n  id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),\n  username      VARCHAR(255) UNIQUE NOT NULL,\n  display_name  VARCHAR(255),\n  created_at    TIMESTAMPTZ DEFAULT NOW(),\n  updated_at    TIMESTAMPTZ DEFAULT NOW()\n);\n\nCREATE TABLE passkeys (\n  id                    UUID PRIMARY KEY DEFAULT gen_random_uuid(),\n  user_id               UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,\n  -- credentialID som base64url-streng (typisk 43-86 tegn)\n  credential_id         TEXT UNIQUE NOT NULL,\n  -- credentialPublicKey som BYTEA (COSE-kodet offentlig n\u00f8gle, 77-300 bytes)\n  public_key            BYTEA NOT NULL,\n  -- Counter til clone-detection (opdateres ved hvert login)\n  counter               BIGINT NOT NULL DEFAULT 0,\n  -- 'singleDevice' eller 'multiDevice' (synkroniseret passkey)\n  device_type           VARCHAR(20) NOT NULL DEFAULT 'singleDevice',\n  -- true = passkey synkroniseret via iCloud\/Google\/Microsoft sky\n  backed_up             BOOLEAN NOT NULL DEFAULT FALSE,\n  -- ['internal'], ['usb'], ['nfc'], ['ble'] etc.\n  transports            TEXT[],\n  -- Navn brugeren giver enheden (valgfrit, til UI)\n  friendly_name         VARCHAR(255),\n  last_used_at          TIMESTAMPTZ,\n  created_at            TIMESTAMPTZ DEFAULT NOW()\n);\n\n-- Indeks til hurtig opslag under authentication\nCREATE INDEX idx_passkeys_credential_id ON passkeys(credential_id);\nCREATE INDEX idx_passkeys_user_id ON passkeys(user_id);\n\n-- Funktion til at opdatere counter og last_used_at atomisk\nCREATE OR REPLACE FUNCTION update_passkey_counter(\n  p_credential_id TEXT,\n  p_new_counter   BIGINT\n) RETURNS VOID AS $$\nBEGIN\n  UPDATE passkeys\n  SET    counter      = p_new_counter,\n         last_used_at = NOW()\n  WHERE  credential_id = p_credential_id\n    AND  counter < p_new_counter; -- Kun opdater hvis ny counter er st\u00f8rre\n  IF NOT FOUND THEN\n    RAISE EXCEPTION 'Counter validation fejlede for credential %', p_credential_id;\n  END IF;\nEND;\n$$ LANGUAGE plpgsql;<\/code><\/pre>\n\n\n\n
I Node.js gemmer du credentialPublicKey<\/code> (som er en Uint8Array<\/code> fra SimpleWebAuthn) direkte i PostgreSQL som BYTEA<\/code> via pg<\/code>-pakken. PostgreSQL behandler automatisk Buffer<\/code>-objekter som bin\u00e6re data. N\u00e5r du l\u00e6ser publicKey tilbage, f\u00e5r du en Buffer<\/code>, som SimpleWebAuthn accepterer direkte i verifyAuthenticationResponse()<\/code>.<\/p>\n\n\n\n
\/\/ Gem credential med pg-pakken (node-postgres)\nconst { Pool } = require('pg');\nconst pool = new Pool({ connectionString: process.env.DATABASE_URL });\n\n\/\/ Gem ny credential efter registrering\nasync function saveCredential(userId, credential, deviceType, backedUp, transports) {\n  await pool.query(\n    `INSERT INTO passkeys\n       (user_id, credential_id, public_key, counter, device_type, backed_up, transports)\n     VALUES ($1, $2, $3, $4, $5, $6, $7)`,\n    [\n      userId,\n      credential.id,                    \/\/ base64url string\n      Buffer.from(credential.publicKey), \/\/ Uint8Array -> Buffer -> BYTEA\n      credential.counter,\n      deviceType,\n      backedUp,\n      transports,\n    ]\n  );\n}\n\n\/\/ Hent credentials til authentication options\nasync function getCredentialsByUserId(userId) {\n  const result = await pool.query(\n    'SELECT * FROM passkeys WHERE user_id = $1 ORDER BY last_used_at DESC NULLS LAST',\n    [userId]\n  );\n  return result.rows.map(row => ({\n    credentialID:        row.credential_id,\n    credentialPublicKey: row.public_key,  \/\/ Buffer fra PostgreSQL\n    counter:             Number(row.counter),\n    transports:          row.transports || [],\n    credentialBackedUp:  row.backed_up,\n  }));\n}\n\n\/\/ Opdater counter atomisk efter succesfuldt login\nasync function updateCounter(credentialId, newCounter) {\n  await pool.query(\n    'SELECT update_passkey_counter($1, $2)',\n    [credentialId, newCounter]\n  );\n}<\/code><\/pre>\n\n\n\n
Brug den atomiske update_passkey_counter()<\/code>-funktion frem for en simpel UPDATE, da den sikrer, at t\u00e6llerv\u00e6rdien altid stiger. Hvis to samtidige login-requests med samme credential lander (fx ved netv\u00e6rksfejl og retry), vil kun den f\u00f8rste opdatere counteren, og den anden vil kaste en fejl, der logger brugeren ud. Dette er den korrekte adf\u00e6rd til clone-detection.<\/p>\n\n\n\n
Overvej at tilf\u00f8je en friendly_name<\/code>-kolonne til passkeys-tabellen, som brugeren kan redigere. I credential-management-UI'en kan du vise \"iPhone 15 Pro (Touch ID)\" og \"MacBook Pro (Touch ID)\" i stedet for hex-strenge. Udfyld den automatisk ved registrering via req.headers['user-agent']<\/code>-parsing for en bedre brugeroplevelse.<\/p>\n\n\n\n
Relateret indhold<\/h2>\n\n\n\n
Vigtige guides til Node.js-sikkerhed<\/h3>\n\n\n\n