Passkey-beredskapstest — Testa WebAuthn

Passkeys ersätter många lösenordsflöden med credentials skyddade av din enhet. Denna guide förklarar exakt vad denna kontroll testar, hur du testar telefonen eller datorn i din hand, vad WebAuthn‑resultat betyder, och varför detta verktyg aldrig ber om dina kontouppgifter.

What does this tool test?

Detta verktyg testar den enhet och webbläsare du använder nu. Öppna sidan på den telefon, platta eller dator du vill utvärdera och tryck sedan på knappen för säker supporttest. Det kontrollerar om den aktuella sidan är ett secure context, om webbläsaren exponerar PublicKeyCredential API, om en plattformsautenticator finns tillgänglig och om conditional mediation stöds. Det testar inte en annan telefon på distans och granskar inte dina konton.

What is a passkey?

En passkey är en WebAuthn‑credential som låter en tjänst autentisera dig med en enhetsupplåsningsmetod som Face ID, Touch ID, Android‑biometri, Windows Hello eller enhets‑PIN. Den privata nyckeln förblir skyddad av credential‑providern; webbplatsen tar emot en publik nyckel och ett signerat svar vid inloggning. Denna design kan motstå många phishing‑ och lösenordsåteranvändningsattacker, men kvaliteten på hela inloggningsupplevelsen beror fortfarande på tjänstens implementation och val för kontåterställning.

What does Supported mean?

Supported betyder att webbläsaren exponerade relevant capability API eller rapporterade ett positivt resultat. Det är en stark indikation på att enheten kan delta i passkey‑flöden. Det är inte ett löfte om att varje webbplats kommer att fungera: sajten måste använda HTTPS, implementera WebAuthn korrekt, skapa en challenge, verifiera svaret på sin server och hantera registrering av konton. Webbläsarinställningar, företagsregler och enhetens skärmlås kan också påverka slutupplevelsen.

What does Unavailable mean?

Unavailable kan betyda att webbläsaren saknar API:et, sidan inte är säker, enheten saknar en kvalificerad plattformsautenticator, en permissions‑check misslyckades eller att webbläsaren inte exponerar den valfria capability. Pröva samma sida i en aktuell webbläsare över HTTPS, se till att ett skärmlås eller biometrisk metod är konfigurerad, och testa igen. Ett negativt resultat här betyder inte att kontot är trasigt; det beskriver bara denna webbläsare och enhet i detta ögonblick.

Why is there no email or password field?

Checkern är avsiktligt konto‑fri. Den mäter webbläsar‑ och enhetskapabilitet utan att skapa en credential, logga in på ett konto eller överföra personuppgifter. En riktig passkey‑registrering kräver en relying party‑server som utfärdar en challenge och lagrar den publika credential. Att be om en e‑postadress här skulle inte göra kapabilitetstestet mer träffsäkert och skulle införa onödig insamling av persondata.

How to test different devices

För att testa en iPhone öppnar du verktyget i Safari på den iPhonen. För Android, öppna i Chrome eller annan stödd webbläsare på Android‑telefonen. För Windows Hello, öppna verktyget på Windows‑datorn och säkerställ att Windows Hello är konfigurerat. För en Mac, använd en aktuell webbläsare och Macens Touch ID eller enhetens säkerhetsinställningar. Tryck alltid på knappen på den enhet du vill mäta.

Privacy and limitations

Checkern läser endast webbläsarens capability APIs. Den skapar, lagrar eller överför aldrig en passkey. Resultat kan ändras efter webbläsaruppdateringar, ändringar i enhetspolicy, skärmlåsförändringar eller när sidan serveras utan HTTPS. För produktionsimplementation måste utvecklare testa registrering, autentisering, återställning, synkronisering och cross‑device‑flöden med en riktig WebAuthn‑server.

What developers must implement on the server

En webbläsarkapabilitetskontroll är bara ett första steg i en riktig passkey‑utrullning. En relying party måste generera en färsk challenge, skicka den till webbläsaren, verifiera den returnerade assertionen på servern och binda credential till rätt konto. Registrering och autentisering behöver tydliga origin‑ och relying‑party‑identifierare, användarverifieringspolicy, replay‑skydd och säker felhantering. Servern bör lagra credential ID, publik nyckel, counter och relevant användarmetadata — inte den privata nyckeln.

Relaterade Pratix-verktyg