Passkeys i produktion: Implementera WebAuthn i Next.js

Lösenordet är den enskilt svagaste länken i de flesta system. Det återanvänds, det nätfiskas, det läcker i dataintrång och det kräver MFA ovanpå för att vara hyfsat säkert. Passkeys är branschens svar: en lösenordsfri inloggning byggd på WebAuthn-standarden, som med ett slag eliminerar hela kategorier av attacker. Den här guiden visar varför passkeys är värda att införa och hur du gör det i en Next.js-applikation.

Jag implementerar lösenordsfri autentisering inom cybersäkerhet, ofta som en del av ett bredare identitetsarbete. Passkeys är ett av få säkerhetssteg som samtidigt förbättrar användarupplevelsen, vilket gör dem ovanligt lätta att motivera. Normalt innebär bättre säkerhet mer friktion för användaren, fler lösenordskrav, fler engångskoder, fler steg. Passkeys bryter det mönstret: de är både säkrare och smidigare, eftersom användaren bara verifierar med fingeravtryck eller ansikte istället för att minnas och knappa in något. Det är sällsynt att kunna säga till en ledningsgrupp att en säkerhetsinvestering också gör produkten trevligare att använda.

Varför passkeys slår lösenord och OTP

En passkey är ett kryptografiskt nyckelpar. Den privata nyckeln lämnar aldrig användarens enhet; servern lagrar bara den publika nyckeln. Det betyder att det inte finns någon delad hemlighet att stjäla, ett intrång i er databas läcker inga lösenord, för det finns inga. Lika viktigt: passkeys är bundna till domänen, vilket gör dem motståndskraftiga mot nätfiske. En användare kan inte luras att använda sin passkey på en falsk sajt, eftersom webbläsaren vägrar. Det är ett steg bortom även SMS- och app-baserad OTP, som fortfarande kan nätfiskas.

Det är värt att stanna vid just nätfiskeskyddet, eftersom det är den egenskap som gör störst praktisk skillnad. De flesta lyckade kontokapningar idag sker inte genom att någon knäcker ett lösenord, utan genom att en användare luras att skriva in sina uppgifter, och även sin engångskod, på en falsk inloggningssida som ser äkta ut. Eftersom en passkey är matematiskt bunden till den riktiga domänen finns det helt enkelt ingenting för användaren att råka lämna ifrån sig på en bluffsajt. Skyddet sitter i tekniken, inte i användarens vaksamhet, och det är en avgörande skillnad. Att flytta säkerheten från mänsklig uppmärksamhet till protokollnivå är precis vad som behövs när nätfisket blir allt mer övertygande.

WebAuthn i korthet

Passkeys bygger på WebAuthn, en webbstandard som hanteras av webbläsaren. Flödet har två delar. Vid registrering skapar enheten ett nyckelpar, behåller den privata nyckeln säkert och skickar den publika till servern. Vid autentisering ber servern enheten signera en utmaning med den privata nyckeln, och verifierar signaturen mot den lagrade publika nyckeln. Användaren upplever det bara som en fingeravtrycks- eller ansiktsverifiering.

Det eleganta med den här konstruktionen är att den bygger på asymmetrisk kryptografi, samma välbeprövade princip som säkrar mycket av internets infrastruktur. Den privata nyckeln, som är den känsliga delen, lämnar aldrig användarens enhet och skyddas där av enhetens säkra hårdvara. Servern hanterar bara publika nycklar, som inte är hemliga och inte kan användas för att logga in. Det betyder att hela kategorin av attacker som bygger på att stjäla hemligheter från servern, lösenordsdatabasläckor, credential stuffing, helt enkelt inte har något att rikta sig mot. Säkerheten är inbyggd i protokollets design, inte påklistrad i efterhand.

Implementera i Next.js

I en Next.js-applikation hanterar serverkomponenten utmaningar och verifiering, medan klienten anropar webbläsarens WebAuthn-API. I praktiken använder de flesta ett etablerat bibliotek för server- och klientlogiken snarare än att implementera kryptografin själva, det minskar risken för subtila fel. Stegen är:

• Registrering: en server-route genererar registreringsalternativ och en utmaning, klienten skapar credentialet, servern verifierar och lagrar den publika nyckeln knuten till användaren.
• Autentisering: en server-route genererar autentiseringsalternativ, klienten signerar, servern verifierar signaturen och etablerar sessionen.
• Lagring: spara publika nycklar och deras metadata, och tillåt flera passkeys per användare för olika enheter.

Här gör jag mid-vägs alltid en genomgång av er befintliga autentisering, eftersom passkeys oftast införs vid sidan av nuvarande inloggning innan de blir förstahandsval. Vill ni ha det upplägget gjort ingår det i cybersäkerhetsuppdraget.

Synkade kontra enhetsbundna passkeys

En distinktion som är värd att förstå innan ni inför passkeys är skillnaden mellan synkade och enhetsbundna nycklar. Synkade passkeys lagras i ett molnkonto, exempelvis hos användarens plattformsleverantör, och följer med mellan enheter. Det är bekvämt och löser mycket av återställningsproblematiken, eftersom en ny enhet automatiskt får tillgång. Enhetsbundna passkeys lämnar aldrig den fysiska enheten eller säkerhetsnyckeln, vilket ger högre säkerhet men sämre bekvämlighet och kräver en tydligare reservplan. För de flesta konsumentinriktade tjänster är synkade passkeys rätt avvägning; för system med mycket höga säkerhetskrav kan enhetsbundna vara motiverade. Valet påverkar hur ni utformar registrering och återställning, så det bör fattas medvetet tidigt.

Praktiska överväganden

Tre saker är värda att planera för. Återställning: vad händer om en användare tappar sin enhet? Plattformssynkade passkeys (via molnkonton) löser mycket, men ni behöver ändå en genomtänkt återställningsväg. Fallback: under en övergångsperiod behöver de flesta behålla en alternativ inloggning. Flera enheter: tillåt användare att registrera passkeys på flera enheter så att de inte låses ute. Den här typen av identitetsarbete hänger ihop med en bredare Zero Trust-ansats.

Var jag brukar börja

Börja med att erbjuda passkeys som ett tillval vid sidan av befintlig inloggning, inte som en tvingande ersättning från dag ett. Då får användarna vänja sig, ni samlar erfarenhet av återställningsflödena, och ni kan göra passkeys till förstahandsval när andelen användare är hög nog. En tvångsmässig övergång över en natt skapar mest supportärenden. Se hur jag lägger upp liknande uppdrag i kundcase.

Relaterat

• NIS2 artikel 21 i praktiken: Checklista för svenska bolag
• DORA-förordningen för fintech: Vad CTO:n måste veta innan 2027
• Schrems II och dataöverföring till USA 2026: Status och alternativ

Vill du ta det vidare?

Jag implementerar passkeys och WebAuthn i Next.js-applikationer, säkrare inloggning som dessutom är enklare för användarna. Boka ett samtal så går vi igenom er autentisering.