Lektion 09 — Passkeys & framtiden utan lösenord

Föreställ dig en inloggning utan lösenord. Du klickar "logga in", din telefon bekräftar att det är du (Face ID, Touch ID eller PIN), och du är inne. Det finns inget lösenord — för det finns inget att stjäla. Det är passkeys.

01Vad en passkey är (kort sagt)

När du skapar en passkey för t.ex. Google: din enhet genererar två digitala nycklar som hör ihop matematiskt. Den ena (privat) stannar för alltid på enheten, krypterad bakom Face ID / PIN. Den andra (publik) skickas till Google.

När du sen ska logga in: Google säger "bevisa att du har den privata nyckeln". Din enhet använder den privata nyckeln för att signera en utmaning, skickar signaturen. Google verifierar med den publika. Klart.

Den privata nyckeln lämnar aldrig din enhet. Google har bara den publika. Det finns inget lösenord någonstans — varken hos dig eller hos Google. Inget att läcka, inget att stjäla, inget att gissa.

02Lösenord vs passkey — vad skickas?

Den största skillnaden är vad som faktiskt passerar nätverket vid inloggning.

Lösenord så fungerar det

01 Sajt frågar efter lösenord

02 Du skriver in det

03 Lösenordet skickas till sajten

04 Sajten hashar och jämför med sparat värde

05 Om läcka: alla lösenord finns hos anfallaren

Passkey framtiden

01 Sajt skickar utmaning (en slumpsträng)

02 Din enhet ber dig bevisa: Face ID / PIN

03 Enheten signerar utmaningen lokalt

04 Bara signaturen skickas — aldrig privat nyckel

05 Om läcka: inget brukbart finns att läcka

03Vad det betyder konkret

Phishing-immunt: passkeyn binder sig till exakt domän. En phishing-sajt på "google-secure.com" kan inte be om en passkey som är registrerad för "google.com" — den finns helt enkelt inte där.
Inget lösenord att läcka: sajten har bara din publika nyckel. Den är värdelös för en angripare.
Inget att brute-forca: det finns ingen hash att gissa mot.
Snabbare i vardagen: ingen att skriva. En tryckning, en blick, du är inne.

04Var finns passkeys redan? (maj 2026)

Stöd är överallt nu — och listan växer snabbt. Stora sajter där du kan slå på passkey idag:

Google

Apple ID

Microsoft

Amazon

PayPal

eBay

GitHub

X (Twitter)

TikTok

Adobe

Best Buy

Shopify

Swedbank · på väg

Nordea · på väg

Klarna · på väg

05Hur kommer du igång?

Google: gå till myaccount.google.com → Security → Passkeys. Klicka "Create a passkey". Använd Face ID/Touch ID/PIN för att bekräfta.
Apple: nästa gång du loggar in på en sajt som stöder det får du frågan "Save passkey?" — säg ja. Synkas via iCloud Keychain mellan dina Apple-enheter.
Microsoft: gå till account.microsoft.com → Security. Skapa passkey, välj autentiseringssätt.
Bitwarden: sedan 2024 kan Bitwarden vara passkey-leverantör på alla dina enheter. Bra om du vill ha cross-platform synk (Windows ↔ iPhone).

06"Vad om jag tappar telefonen?"

Bra fråga. Två sätt det löses på:

Synkade passkeys (vanligaste typen): din passkey finns inte bara på telefonen utan på alla dina enheter via iCloud Keychain / Google Password Manager / Bitwarden. Tappar du telefonen kommer du åt passkeyen från datorn.
Enhets-bundna passkeys: vissa sajter låter dig registrera flera passkeys (t.ex. telefon + laptop + USB-nyckel). Tappar du en finns de andra kvar.

Och om du tappar alla dina enheter samtidigt: du har fortfarande ditt vanliga konto-återställning (recovery email, backup codes från lektion 8).

07Tar passkeys över? När?

Förmodligen ja, men gradvis. FIDO Alliance (som bygger standarden) räknar med att passkeys är default-inloggning hos stora sajter runt 2027-2028. Lösenord försvinner inte över en natt — men de blir mer och mer som faxar: existerar, men för folk som "inte fixat passkey än".

Min praktiska rekommendation 2026: aktivera passkey på Google, Apple ID, Microsoft, och GitHub om du har det. Sätt 2FA-app som backup. Behåll lösenordshanterare för allt som inte stöder passkeys än.

Passkeys är konsument-rebranding av WebAuthn + FIDO2 CTAP2 — protokoll för publik-nyckel-autentisering på webben. Tekniskt: discoverable credentials med multi-device synk, byggt på samma origin-binding som gör hardware security keys phishing-resistenta.

01Komponenterna

WebAuthn (W3C Recommendation, mars 2019): browser-API för publik-nyckel-autentisering. Exponerar navigator.credentials.create() och navigator.credentials.get().
CTAP2 (Client-to-Authenticator Protocol): låter browsern prata med externa autentikatorer (USB, NFC, BLE).
FIDO2: paraplyterm för WebAuthn + CTAP2 + tillhörande spec.
Passkey: branding för en specifik subset av FIDO2 — discoverable (kan användas utan användarnamn först) och oftast multi-device (synkad mellan användarens enheter).

02Registreringsflödet

1. Site → Browser: credentials.create({user, rp, challenge})
2. Browser → Authenticator (Secure Enclave / TPM): genererar keypair, binder till rp.id
3. Authenticator: lokalt user-verification (biometric / PIN)
4. Authenticator → Browser: { publicKey, credentialId, attestation }
5. Browser → Site: skickar publicKey och credentialId
6. Site sparar: { user_id, credentialId, publicKey }

Den privata nyckeln genereras inuti enhetens säkra hårdvara (Secure Enclave på Apple, StrongBox/TEE på Android, TPM på Windows) och extraheras aldrig — alla signaturoperationer sker inuti säkerhets-chippet.

03Authentication flow & origin binding

Vid inloggning skickar sajten en slumpmässig challenge. Browsern berikar med origin (protocol + hostname + port) och type (webauthn.get) och skickar till authenticator. Authenticator skapar:

authData = rpIdHash || flags || signCount || (clientDataJSON.hashed)
signature = sign(privateKey, authData)

rpIdHash är hashen av sajtens domän — så signaturen är specifik för origin. En phishing-sajt på annan domän kan inte få authenticator att signera för rätt domän, även om användaren själv tillåter det.

Det här är kärnan i phishing-resistens: nyckeln vet vilken sajt den registrerats för och vägrar att signera för andra. Implementerat i hårdvara, inte mjukvara — kan inte bypassas av kompromissad browser.

04Device-bound vs synced passkeys

Device-bound (också kallad non-portable): nyckeln existerar bara på en specifik enhet (typiskt hardware tokens som YubiKey). Maximal säkerhet — om enheten tappas, är det förlorat (registrera flera).
Synced passkeys: nyckeln är kapslad i en E2E-krypterad keychain (iCloud Keychain, Google Password Manager, Bitwarden) och tillgänglig på alla användarens enheter. Bättre UX, marginellt mindre säkert (men fortfarande mycket mer än lösenord).

Vissa relying parties tillåter bara device-bound passkeys för hög-värde-konton (finans, statligt). Discoverable credentials har en residentKey-flagga som indikerar om credentialen är synkbar.

05Attestation

Vid registrering kan authenticator skicka med attestation — ett certifikat som bevisar vilken modell av authenticator det är. Sajter kan välja att bara acceptera vissa modeller (FIPS-certifierade, hardware-bound, specifik tillverkare).

Synced passkeys (Apple/Google) använder typiskt none-attestation eller självsignerat — för att skydda användarens integritet (annars skulle sajter kunna spåra användare mellan konton via attestation-cert).

06Recovery & account linking

Den största praktiska utmaningen är inte säkerhet — utan recovery. Om alla användarens enheter försvinner samtidigt och de inte har backup-mekanism:

Synced passkeys räddar 95 % av fallen — så länge användaren har sitt iCloud/Google-konto är passkeyn återställbar.
Email + 2FA fallback är fortfarande standard i de flesta implementationer. Detta är en survival-vektor som behåller en del av phishing-risken.
Verifierade kontakter / family recovery kommer som standard 2026+ för att eliminera fallback-lösenord.

07Vad krävs på sajt-sidan

Implementera passkey-support är en kvällsuppgift för en backend-utvecklare med modernt språk:

SimpleWebAuthn (Node.js): mest använd JS-implementation.
WebAuthn4J (Java), py_webauthn (Python), fido2-net-lib (.NET).
Auth0, Clerk, Stytch, Hanko: managed auth-leverantörer som hanterar det åt dig.

Datalagring per användare: array av credentials, varje med {credentialId, publicKey, signCount, transports}. Ingen "lösenordshash"-tabell — för det finns ingenting hemligt på sajt-sidan.

08Vad kommer härnäst

Cross-platform cred portability: Apple ↔ Google passkey-export 2025+. Reducerar lock-in.
Hybrid transport over BLE: logga in på datorn med passkey som finns på telefonen, via QR + BLE. Funkar redan idag.
Conditional UI: autofyll-stil prompts som inte avbryter användarens flöde. Spridning under 2025-2026.
FIDO Alliance Levels: standardiserad bedömning av authenticator-säkerhet (L1/L2/L3) — relying parties kan välja minimum-nivå.

Den största förändringen är inte teknisk utan kulturell: passkeys är förmodligen den första autentiserings-teknik som är både säkrare och enklare än vad den ersätter. Lösenord var en kompromiss mellan säkerhet och UX. Passkeys behöver inte kompromissa — vilket är varför adoptionen går snabbare än vad kryptografi-projekt normalt gör.

Passkeys & framtiden utan lösenord.

01Vad en passkey är (kort sagt)

02Lösenord vs passkey — vad skickas?

03Vad det betyder konkret

04Var finns passkeys redan? (maj 2026)

05Hur kommer du igång?

06"Vad om jag tappar telefonen?"

07Tar passkeys över? När?

01Komponenterna

02Registreringsflödet

03Authentication flow & origin binding

04Device-bound vs synced passkeys

05Attestation

06Recovery & account linking

07Vad krävs på sajt-sidan

08Vad kommer härnäst

Snabb-koll — sista tre frågorna

Klart med akademin?