Klucze dostępu (passkeys): logowanie bez hasła i odzyskiwanie konta

Klucze dostępu (ang. passkeys) umożliwiają logowanie bez hasła do aplikacji webowej. Użytkownik potwierdza logowanie odciskiem palca, twarzą lub kodem PIN swojego urządzenia, a serwer zamiast hasła przechowuje klucz publiczny. Dla firmy z portalem klienta lub aplikacją wewnętrzną główną korzyścią jest ochrona przed phishingiem, a nie tylko wygoda.

Sam przycisk „Utwórz klucz dostępu” jednak nie wystarczy. O wyniku decyduje właściwie wybrana domena, bezpieczna rejestracja, zarządzanie urządzeniami, a przede wszystkim odzyskiwanie konta, które nie może pozostać najsłabszym ogniwem. Poniżej znajdziesz przykład poglądowy, procedurę wdrożenia, tabelę decyzyjną, częste błędy i listę kontrolną.

Co rozwiązują klucze dostępu, a czego nie

Klucz dostępu to para kluczy kryptograficznych. Klucz prywatny pozostaje u dostawcy kluczy dostępu użytkownika, czyli w telefonie, komputerze, menedżerze haseł lub w sprzętowym kluczu bezpieczeństwa. Twoja aplikacja przechowuje klucz publiczny. Podczas logowania urządzenie podpisuje wyzwanie serwera dopiero po potwierdzeniu przez użytkownika, zwykle przez odblokowanie urządzenia. Podstawą techniczną jest standard W3C Web Authentication (WebAuthn) Level 3, który od 25 sierpnia 2026 r. jest rekomendacją W3C.

Kluczową korzyścią jest odporność na phishing. Zgodnie ze standardem WebAuthn klucza dostępu można użyć tylko wobec tej samej strony (RP ID, zwykle domeny), dla której został zarejestrowany. Dokumentacja Google dla deweloperów dodaje, że użytkownika nie da się nakłonić do zalogowania na fałszywej stronie, ponieważ weryfikację zapewnia przeglądarka lub system operacyjny.

Amerykańska wytyczna NIST SP 800-63B wprost stwierdza, że metody, w których użytkownik ręcznie przepisuje kod, na przykład jednorazowe kody z SMS lub z aplikacji, nie są odporne na phishing: fałszywa strona może przekazać kod do prawdziwej usługi. WebAuthn podaje natomiast jako przykład standardu odpornego na phishing. Polskiej firmy ta wytyczna do niczego nie zobowiązuje, ale jest dobrze udokumentowanym punktem odniesienia.

Klucze dostępu nie rozwiążą źle ustawionych uprawnień po zalogowaniu, przejętej sesji ani słabego odzyskiwania konta. Jeśli atakujący przekona dział wsparcia, aby „przywrócił mu dostęp”, kryptografia nie pomoże. Dlatego odzyskiwaniu konta poświęcamy osobną część.

Klucze dostępu synchronizowane i powiązane z urządzeniem

WebAuthn rozróżnia dwa typy danych uwierzytelniających. Ich właściwości bezpośrednio wpływają na to, jak zaprojektujesz odzyskiwanie konta.

Typ	Jak działa	Konsekwencja dla aplikacji
Synchronizowany klucz dostępu (multi-device credential)	Dostawca kluczy dostępu może utworzyć jego kopię zapasową i udostępnić go na innych urządzeniach użytkownika.	Utrata jednego urządzenia zwykle nie oznacza utraty dostępu. Na najwyższym poziomie NIST AAL3 nie wolno jednak używać synchronizowanych środków uwierzytelniania.
Klucz dostępu powiązany z urządzeniem (single-device credential)	Nigdy nie ma kopii zapasowej, na przykład klucz dostępu zapisany w sprzętowym kluczu bezpieczeństwa.	Według WebAuthn nie jest odporny na utratę urządzenia, dlatego konto powinno mieć dodatkowy środek uwierzytelniania lub proces odzyskiwania.

Aplikacja rozpoznaje typ na podstawie flag BE (backup eligibility) i BS (backup state) w danych zwracanych przez urządzenie. Standard WebAuthn zaleca przechowywanie ich ostatnich wartości przy koncie. Gdy BS zmieni się z 1 na 0, klucz dostępu nie ma już kopii zapasowej, a aplikacja powinna przeprowadzić użytkownika przez weryfikację pozostałych metod logowania lub dodanie kolejnej.

Przykład: klucze dostępu w portalu B2B dystrybutora

Przykład poglądowy, nie rzeczywisty klient. Dystrybutor prowadzi portal pod adresem portal.example.com, w którym odbiorcy składają zamówienia i pobierają faktury. Pracownicy korzystają z panelu administracyjnego pod adresem admin.example.com. Obecnie wszyscy logują się hasłem, a przy wrażliwych operacjach kodem z SMS.

Wdrożenie mogłoby przebiec w trzech etapach:

Propozycja po zalogowaniu. Po zalogowaniu i weryfikacji e-mailem portal proponuje utworzenie klucza dostępu. Hasło na razie pozostaje jako metoda zapasowa.
Klucz dostępu jako opcja domyślna. Formularz logowania proponuje zapisany klucz dostępu bezpośrednio w podpowiedziach przeglądarki. Kto nie ma klucza dostępu, loguje się po staremu.
Obowiązkowo dla administratorów. Pracownicy z dostępem do cenników i danych odbiorców muszą mieć dwa zarejestrowane środki uwierzytelniania, na przykład klucz dostępu w laptopie i klucz sprzętowy przechowywany w sejfie.

Jeśli klucze dostępu mają działać w obu subdomenach, dystrybutor ustawia RP ID na example.com. Przewodnik web.dev podaje, że przy RP ID example.com użytkownik może zalogować się w login.example.com i w innych subdomenach example.com. Jeśli natomiast portal i panel administracyjny są osobnymi systemami z różnymi kontami, mogą mieć oddzielne RP ID.

Wdrożenie w ośmiu krokach

Zmapuj punkty wejścia i grupy użytkowników. Spisz wszystkie drogi do konta: formularz logowania, aplikację mobilną, przypomnienie hasła, zmianę adresu e-mail i dział wsparcia. Dla każdej grupy określ, czy klucz dostępu będzie opcjonalny, zalecany czy obowiązkowy.
Wybierz RP ID przed pierwszą rejestracją. Według WebAuthn domyślnym RP ID jest domena strony; można je też ustawić na jej rejestrowalną domenę nadrzędną. Klucz dostępu działa tylko z RP ID, dla którego powstał, więc po późniejszej zmianie użytkownicy muszą utworzyć go ponownie.
Przed utworzeniem klucza dostępu zweryfikuj użytkownika mocniej niż hasłem. web.dev zaleca weryfikację na przykład e-mailem lub telefonem w krótkim oknie czasowym i ostrzega przed weryfikacją samym hasłem: mając wykradzione hasło, atakujący utworzyłby własny klucz dostępu. Listę już zarejestrowanych kluczy dostępu przesyłaj w parametrze excludeCredentials, aby nie powstawały duplikaty.
Na serwerze użyj sprawdzonej biblioteki. web.dev zaleca przetwarzanie odpowiedzi przeglądarki biblioteką po stronie serwera, a nie własnym kodem. Zapisz identyfikator danych uwierzytelniających, klucz publiczny, identyfikator użytkownika, AAGUID (identyfikator dostawcy kluczy dostępu, na podstawie którego nazwiesz klucz dostępu), flagi BE i BS oraz datę utworzenia i ostatniego użycia. Nie umieszczaj w user.id danych osobowych, na przykład adresu e-mail.
Pokazuj propozycję tylko tam, gdzie działa. Metodą PublicKeyCredential.getClientCapabilities() sprawdzisz, czy urządzenie obsługuje klucze dostępu oraz ich podpowiadanie bezpośrednio w formularzu logowania. Przy wrażliwych operacjach sprawdzaj flagę UV, ponieważ przy ustawieniu userVerification: "preferred" urządzenie może pominąć weryfikację użytkownika.
Wysyłaj powiadomienia. Po dodaniu klucza dostępu wyślij użytkownikowi e-mail. Według web.dev klucz dostępu, który atakujący utworzy bez wiedzy użytkownika, pozostaje użyteczny nawet po zmianie hasła; powiadomienie pomaga wykryć taki dostęp.
Dodaj stronę zarządzania kluczami dostępu. Użytkownik powinien widzieć nazwę, datę utworzenia, ostatnie użycie i to, czy klucz dostępu jest synchronizowany, a także móc go od razu usunąć. NIST wymaga, aby środek uwierzytelniania można było unieważnić natychmiast po zgłoszeniu jego utraty lub kradzieży.
Uruchom pilotaż i go oceń. Zacznij od mniejszej grupy użytkowników. Śledź skuteczność rejestracji, błędy logowania, liczbę odzyskań konta i zgłoszenia do wsparcia. Dopiero potem ustaw klucz dostępu jako opcję domyślną.

Odzyskiwanie konta: najsłabsze ogniwo, jeśli go nie zaprojektujesz

Jeśli klucz dostępu można obejść linkiem „nie pamiętam hasła” lub jednym kodem z SMS, konto jest tak bezpieczne jak ta ścieżka. NIST SP 800-63B wyróżnia cztery klasy odzyskiwania: zapisane kody odzyskiwania, wysyłane kody odzyskiwania, kontakty do odzyskiwania oraz ponowne potwierdzenie tożsamości. Inną procedurę, na przykład przez pracownika wsparcia, dopuszcza tylko na podstawie analizy ryzyka i z dokumentacją.

Kilka metod logowania z wyprzedzeniem

NIST zaleca zachęcanie użytkowników do utrzymywania co najmniej dwóch odrębnych metod uwierzytelniania i wymaga, aby do konta można było powiązać wiele środków uwierzytelniania. Najlepsze odzyskiwanie to takie, którego nie trzeba używać: drugi klucz dostępu na innym urządzeniu lub klucz sprzętowy.

Kody odzyskiwania

Według NIST zapisany kod odzyskiwania musi zawierać co najmniej 64 bity z generatora liczb losowych, jest przechowywany wyłącznie jako hash, jego weryfikacja podlega ograniczeniu liczby prób, a po użyciu kod jest unieważniany i wydawany jest nowy. Kod wysłany e-mailem może być ważny najwyżej 24 godziny, a SMS-em lub połączeniem głosowym najwyżej 10 minut. Dla kont na poziomie AAL2 NIST wymaga dwóch kodów uzyskanych różnymi metodami, jednego kodu wraz z uwierzytelnieniem innym środkiem powiązanym z kontem albo ponownego potwierdzenia tożsamości, jeśli tożsamość była pierwotnie potwierdzona.

Wsparcie i powiadomienia

Według NIST każde odzyskanie konta musi wywołać powiadomienie użytkownika. Przygotuj dla działu wsparcia spisaną procedurę: co weryfikuje, kto zatwierdza wyjątki i co trafia do dziennika audytowego. Bez niej ręczne odzyskiwanie jest miejscem, w którym socjotechnika obejdzie nawet najlepszą technologię.

Tabela decyzyjna według grup użytkowników

Grupa	Zalecane podejście	Odzyskiwanie konta	Na co uważać
Klienci portalu lub sklepu internetowego o niskim ryzyku	Klucz dostępu jako opcja obok dotychczasowego logowania, proponowana po zalogowaniu	Kod wysyłany e-mailem z krótką ważnością i zapisany kod odzyskiwania	Nie utrudniać logowania tym, którzy nie chcą klucza dostępu
Odbiorcy B2B z dostępem do faktur i zamówień	Klucz dostępu zalecany, co najmniej dwie metody logowania, ponowne uwierzytelnienie przy wrażliwych operacjach	Dwie niezależne metody odzyskiwania i powiadomienie o każdym odzyskaniu	Współdzielone konta firmowe – każda osoba powinna mieć własne konto
Administratorzy i pracownicy z dostępem do danych	Klucz dostępu obowiązkowy; tam, gdzie wymagają tego zasady wewnętrzne, sprzętowe klucze powiązane z urządzeniem	Drugi zarejestrowany klucz i udokumentowana procedura przez wyznaczoną osobę	Jeśli wymagasz poziomu NIST AAL3, synchronizowane klucze dostępu nie wystarczą

Tabela wyraża naszą rekomendację, a nie normę. Granice między grupami ustal w zależności od tego, jakie dane i operacje są dostępne po zalogowaniu.

Zalety i kompromisy

Mniejsze szkody przy wycieku bazy danych. W przypadku kont z kluczem dostępu serwer przechowuje klucz publiczny zamiast hasła. Google podaje, że atakujący zdobywa wtedy znacznie mniej wartościowe dane, a po incydencie jest mniej sprzątania.
Mniej kodów SMS. Według Google klucze dostępu mogą wyeliminować potrzebę jednorazowych kodów z SMS lub aplikacji przy logowaniu, co obniża też koszty SMS.
Kompromis: zapasowe hasło. Dopóki hasło pozostaje alternatywą, phishing nadal na nie działa. Częścią wdrożenia powinien być plan, kiedy i komu usuniesz hasło.
Kompromis: zależność od dostawcy kluczy dostępu. Synchronizowanymi kluczami dostępu zarządza usługa użytkownika, na przykład konto w chmurze lub menedżer haseł. Ochrona tej kopii zapasowej leży poza Twoją aplikacją.
Kompromis: więcej pracy w utrzymaniu. Dochodzi rejestracja, zarządzanie urządzeniami, powiadomienia i nowa procedura odzyskiwania. Dział wsparcia potrzebuje instrukcji, zanim pojawią się pierwsze pytania.

Częste błędy

Tworzenie klucza dostępu po podaniu samego hasła, bez dodatkowej weryfikacji.
Brak powiadomienia o nowym kluczu dostępu lub o odzyskaniu konta.
Odzyskiwanie jednym kodem z SMS, które omija klucze dostępu i wszystkie inne zabezpieczenia.
RP ID wybrane w pośpiechu, na przykład tylko dla www, i później zmienione.
Dane osobowe w user.id.
Użytkownik nie ma gdzie zobaczyć ani usunąć swoich kluczy dostępu.
Własna weryfikacja podpisów zamiast sprawdzonej biblioteki.

Lista kontrolna przed uruchomieniem

RP ID jest ustalone i przetestowane we wszystkich domenach, w których logują się użytkownicy.
Przed rejestracją klucza dostępu następuje weryfikacja mocniejsza niż hasło.
Serwer zapisuje identyfikator danych uwierzytelniających, klucz publiczny, AAGUID, flagi BE i BS oraz daty użycia.
Użytkownik otrzymuje powiadomienie o nowym kluczu dostępu i o każdym odzyskaniu konta.
Strona zarządzania kluczami dostępu umożliwia natychmiastowe usunięcie.
Każde konto z kluczem dostępu powiązanym z urządzeniem ma drugi środek uwierzytelniania lub odzyskiwanie.
Kody odzyskiwania są jednorazowe, przechowywane jako hash i chronione ograniczeniem liczby prób.
Dział wsparcia ma spisaną procedurę odzyskiwania i dziennik audytowy.

Najczęściej zadawane pytania

Czy możemy całkowicie zrezygnować z haseł?

Tak, ale stopniowo. WebAuthn podaje, że gdy klucz dostępu zyska kopię zapasową (flaga BS zmieni się z 0 na 1), aplikacja może zaproponować użytkownikowi usunięcie hasła. Zalecamy robić to dopiero wtedy, gdy użytkownik ma co najmniej dwie metody logowania i działające odzyskiwanie konta.

Co, jeśli użytkownik zgubi telefon?

Synchronizowany klucz dostępu jest zwykle dostępny także na innych jego urządzeniach, więc zaloguje się na przykład z laptopa. W razie podejrzenia nadużycia usuwa klucz dostępu w aplikacji i tworzy nowy. Klucz dostępu powiązany z urządzeniem przepada razem z urządzeniem, dlatego WebAuthn zaleca, aby konto miało dodatkowy środek uwierzytelniania lub proces odzyskiwania.

Czy aplikacja przechowuje odciski palców lub skany twarzy?

Nie. Odblokowanie odciskiem palca, twarzą lub kodem PIN odbywa się na urządzeniu użytkownika, a według Google serwer przechowuje klucz publiczny. Lista danych, które web.dev zaleca zapisywać, nie zawiera danych biometrycznych.

Czy jednorazowy kod SMS wystarczy jako alternatywa?

Nie chroni przed phishingiem: NIST nie uznaje jednorazowych kodów przepisywanych przez użytkownika za odporne na phishing, ponieważ fałszywa strona może je przekazać dalej. Jeśli użyjesz SMS przy odzyskiwaniu konta, NIST ogranicza ważność wysłanego kodu do 10 minut. Przy wrażliwych kontach zalecamy klucz dostępu jako główną metodę, a SMS najwyżej jako jedną ze ścieżek odzyskiwania.

Jak możemy pomóc

Klucze dostępu można dodać także do istniejącej aplikacji, bez przepisywania całego systemu. W ramach tworzenia aplikacji webowych na zamówienie zaprojektujemy i wdrożymy rejestrację, logowanie, zarządzanie kluczami dostępu i odzyskiwanie konta oraz przygotujemy procedurę dla działu wsparcia. Więcej praktycznych poradników znajdziesz na naszym blogu.

Rozważasz logowanie bez hasła w portalu klienta lub aplikacji wewnętrznej? Napisz do nas, a wspólnie ustalimy, od czego zacząć i co przygotować.

Źródła

Web Authentication: An API for accessing Public Key Credentials – Level 3 – W3C, rekomendacja z 25 sierpnia 2026 r.
NIST Special Publication 800-63B – wytyczna NIST dotycząca uwierzytelniania i zarządzania środkami uwierzytelniania, część rewizji SP 800-63-4.
Create a passkey for passwordless logins – web.dev, aktualizacja z 9 kwietnia 2026 r.
Passkeys – Google for Developers.