Passkeys zamiast haseł: czy wdrożyć klucze dostępu w aplikacji i na stronie

Co to jest passkey i jak działa logowanie bez hasła?

Passkey to dane logowania oparte na standardach FIDO, które zastępują hasło parą kluczy kryptograficznych. Przy zakładaniu klucza urządzenie klienta tworzy dwa klucze: prywatny zostaje w telefonie, komputerze albo menedżerze haseł, a publiczny trafia na Twój serwer. Przy logowaniu serwer wysyła zadanie do podpisania, a urządzenie podpisuje je kluczem prywatnym dopiero po odblokowaniu odciskiem palca, twarzą albo PIN-em. FIDO Alliance podkreśla, że dane biometryczne zostają na urządzeniu i nigdy nie są wysyłane na żaden serwer, więc Twoja firma ich nie przetwarza. Klucz jest przypisany do konkretnej domeny, dlatego fałszywa strona podszywająca się pod Twoją nie może go użyć. Na tym polega odporność na phishing, której nie daje ani hasło, ani kod SMS przepisywany ręcznie przez klienta. Klucze mogą być synchronizowane między urządzeniami jednego użytkownika, na przykład przez pęk kluczy iCloud albo Menedżer haseł Google, albo przypisane do jednego urządzenia, na przykład klucza sprzętowego.

Passkey, hasło, kod SMS czy logowanie przez Google: porównanie

Passkey jako jedyna z popularnych metod łączy odporność na phishing z brakiem sekretu, który dałoby się wykraść z Twojej bazy. Porównanie z perspektywy firmy, która prowadzi konta klientów:

Ile naprawdę dają passkeys? Dane z 2026 roku

Najświeższe dane pochodzą z Passkey Index FIDO Alliance, opublikowanego 15 października 2026 roku na podstawie danych 15 serwisów konsumenckich, w tym Amazon, Google, Microsoft, PayPal, Shopify, TikTok i WhatsApp, zebranych 21 września 2026 roku. To średnie nieważone z dużych serwisów, więc mała firma nie powinna oczekiwać identycznych wyników, ale kierunek jest jednoznaczny. Rok wcześniej ten sam raport miał 9 uczestników, więc porównania rok do roku są orientacyjne.

Czy passkeys działają na telefonach i komputerach Twoich klientów?

Tak, na prawie wszystkich telefonach i komputerach z ostatnich lat: klucze synchronizowane wymagają co najmniej Androida 9, iOS lub iPadOS 16 albo macOS 13. W serwisach z Passkey Index z passkeys mogło korzystać 90% aktywnych kont. Zestawienie z passkeys.dev, strony prowadzonej przez członków W3C i FIDO Alliance (aktualizacja 21 września 2026):

• Klient, który ma klucz tylko w telefonie, zaloguje się na innym komputerze przez kod QR: skanuje go telefonem i potwierdza logowanie. Google podaje, że to logowanie między urządzeniami działa na wszystkich platformach Chrome, a na Windows według passkeys.dev od wersji 23H2.
• Aplikacja na Androida korzysta z Credential Manager, który obsługuje passkeys od Androida 9. Aplikacja na iOS korzysta z AuthenticationServices.
• Starsze urządzenia nie znikną z dnia na dzień, dlatego hasło albo inna metoda logowania zostaje jako zapasowa.

Co się stanie, gdy klient zgubi telefon albo przejdzie z iPhone'a na Androida?

Klucz synchronizowany wraca razem z kontem Apple albo Google na nowym urządzeniu, a przy zmianie ekosystemu klient loguje się kodem QR ze starego telefonu albo metodą zapasową i tworzy nowy klucz. Od systemów Apple w wersji 26 klucze można też bezpiecznie przenosić między menedżerami haseł, które obsługują tę funkcję, co Apple pokazało na WWDC25. Dla Twojego systemu oznacza to trzy rzeczy. Po pierwsze, jedno konto powinno mieć kilka kluczy, na przykład z telefonu i z komputera. Po drugie, odzyskiwanie konta, zwykle przez e-mail albo telefon, staje się najsłabszym ogniwem, więc musi być zabezpieczone tak samo starannie jak logowanie, bo atakujący zaatakuje właśnie je. Po trzecie, NIST w wytycznych SP 800-63B-4 zwraca uwagę, że klucze synchronizowane mogą być współdzielone, na przykład w rodzinie, więc przy usługach wymagających pewności, kto się loguje, potrzebujesz dodatkowych zabezpieczeń.

Jak jeden klucz działa jednocześnie w aplikacji i na stronie?

Klucz jest przypisany do domeny, na przykład firma.pl, a aplikację mobilną trzeba z tą domeną formalnie powiązać. Na Androidzie służy do tego plik Digital Asset Links na serwerze, a w iOS powiązana domena z usługą webcredentials. Apple w dokumentacji pisze wprost, że bez takiej powiązanej domeny próba utworzenia albo użycia klucza kończy się błędem. Po poprawnym powiązaniu klient tworzy klucz raz, na przykład w aplikacji, i loguje się nim także w przeglądarce na stronie. Z tego wynika praktyczna rada: domenę, do której przypiszesz klucze, wybierz z myślą o latach. Supabase w opisie swojej funkcji wymaga, żeby identyfikator serwisu był samą domeną, bez protokołu, portu i ścieżki. Jeśli strona i aplikacja działają na różnych domenach, zaplanuj to przed wdrożeniem. Jak wybrać między aplikacją a serwisem w przeglądarce, piszemy we wpisie aplikacja webowa czy mobilna.

Jak wdrożyć passkeys krok po kroku?

1. Ustal, gdzie klienci się logują: sklep, panel klienta, aplikacja mobilna. Passkeys mają sens tam, gdzie logowanie jest częste albo konto jest cenne.
2. Wybierz sposób: własny serwer z biblioteką zgodną ze standardem WebAuthn albo usługa logowania, która ma passkeys. Supabase udostępnia je od 28 maja 2026 roku jako wersję beta z eksperymentalnym API, które według Supabase może się zmienić bez zapowiedzi. Porównanie obu usług znajdziesz we wpisie Supabase czy Firebase.
3. Powiąż aplikację z domeną plikami Digital Asset Links i apple-app-site-association.
4. Proponuj utworzenie klucza w dobrych momentach. Google wymienia: zaraz po zalogowaniu hasłem, w ustawieniach bezpieczeństwa konta, po odzyskaniu konta i po ponownym potwierdzeniu tożsamości przed ważną operacją. Nowsze systemy, na przykład iOS 18 i Chrome 136 na komputerach, potrafią też utworzyć klucz automatycznie po zalogowaniu hasłem.
5. Włącz podpowiedź klucza w polu logowania (autouzupełnianie), żeby klient nie musiał szukać osobnego przycisku.
6. Zostaw metodę zapasową i zabezpiecz odzyskiwanie konta. Google zaleca e-mail, telefon albo logowanie przez Google jako drogę powrotu po utracie kluczy.
7. Przy usuwaniu konta albo zmianie nazwy użytkownika informuj menedżer kluczy klienta przez Signal API, żeby nie podpowiadał nieaktualnych danych. O samym usuwaniu konta piszemy w tekście usuwanie konta w aplikacji.
8. Mierz dwie liczby: odsetek kont z kluczem i odsetek logowań kluczem. FIDO pokazuje, że różnica między nimi mówi, czy klienci faktycznie z klucza korzystają.

Ile kosztuje wdrożenie passkeys i co można zaoszczędzić?

Koszt to głównie praca nad serwerem, ekranami logowania, odzyskiwaniem konta i testami na różnych telefonach. Przy nowej aplikacji passkeys projektuje się razem z resztą logowania, więc to część zakresu, a nie osobny projekt. Przy istniejącym systemie trzeba doliczyć zmiany w bazie kont i testy dotychczasowych ścieżek logowania. Oszczędności zależą od skali. W Passkey Index wszyscy czterej uczestnicy, którzy podali dane o kosztach, płacą mniej za kody SMS, ale to bardzo duże serwisy z rocznymi oszczędnościami od około miliona dolarów wzwyż. Mała firma zyska raczej mniej zgłoszeń typu „nie pamiętam hasła” i mniejsze ryzyko przejęcia kont klientów niż duże kwoty na SMS-ach. Nie znaleźliśmy wiarygodnych publicznych danych o oszczędnościach małych firm, dlatego ich nie podajemy.

Kiedy passkeys mają sens, a kiedy jeszcze nie?

Sklep internetowy z kontami klientów

Tak. Szybsze logowanie przy zamówieniu, mniej nieudanych logowań i mniej przejętych kont.

Aplikacja z rezerwacjami, kartą lojalnościową albo panelem klienta

Tak, szczególnie gdy klienci logują się co jakiś czas i zapominają haseł.

Serwis z płatnościami albo danymi wrażliwymi

Tak, jako metoda główna, z bardzo starannie zaprojektowanym odzyskiwaniem konta.

Strona firmowa bez kont klientów

Nie dotyczy. Zadbaj za to o klucze dostępu do własnych kont: hostingu, domeny, poczty i panelu strony.

Aplikacja dla pracowników z logowaniem kontem firmowym

Zwykle klucze konfiguruje się w systemie tożsamości firmy, a nie w samej aplikacji.

Klienci głównie na bardzo starych telefonach

Na razie jako opcja dodatkowa, a nie jedyna.

Słabe strony passkeys

• Odzyskiwanie konta: gdy klient straci wszystkie urządzenia i dostęp do konta Apple lub Google, wraca do metody zapasowej, która jest słabsza niż sam klucz.
• Zależność od ekosystemu: klucze synchronizują się w obrębie Apple albo Google, a przejście między nimi wymaga kodu QR, ponownego utworzenia klucza albo eksportu w nowszych systemach.
• Współdzielenie: klucz synchronizowany może trafić do innych osób w rodzinie, na co zwraca uwagę NIST.
• Dwie metody naraz: przez lata utrzymujesz klucze i hasło, więc kodu do zabezpieczenia jest więcej, a nie mniej.
• Zrozumienie przez klientów: nazwa „klucz dostępu” bywa myląca, dlatego Google publikuje osobne wskazówki, jak mówić o passkeys użytkownikom.
• Młode narzędzia: część usług logowania ma passkeys dopiero w wersji beta, z interfejsem, który może się zmienić.

Co zalecają instytucje i duże firmy?

Brytyjskie NCSC 23 kwietnia 2026 roku zaleciło, żeby passkeys były pierwszym wyborem konsumentów i domyślną opcją logowania, którą firmy oferują klientom. Amerykański NIST w wytycznych SP 800-63B-4 dopuszcza klucze synchronizowane do poziomu AAL2, pod warunkiem że dostęp do nich w chmurze chroni uwierzytelnianie wieloskładnikowe. Microsoft od 1 maja 2025 roku zakłada nowe konta domyślnie bez hasła. W Polsce nie znaleźliśmy oficjalnego zalecenia CERT Polska ani innego urzędu dotyczącego passkeys, stan na październik 2026. Wytyczne App Store Review również nie wymagają passkeys, ale jeśli w aplikacji jest logowanie przez Google albo Facebooka, obowiązuje wytyczna 4.8, którą opisujemy we wpisie logowanie przez Google lub Facebooka a zasady Apple.

Nasze zdanie

W nowych aplikacjach i panelach klienta proponujemy passkeys od początku, obok logowania e-mailem, bo dodanie ich na etapie projektu jest prostsze niż późniejsza przebudowa. W istniejącym systemie zaczynamy od propozycji utworzenia klucza po zalogowaniu i od uszczelnienia odzyskiwania konta, a hasło zostawiamy jako metodę zapasową. Nie obiecujemy, że passkeys rozwiążą wszystkie problemy z bezpieczeństwem: co zrobić, gdy coś już się stało, opisujemy w tekście strona firmy zhakowana: co zrobić. Logowanie projektujemy w ramach tworzenia aplikacji mobilnych i stron internetowych z kontami klientów. Aplikacje zaczynają się u nas od 11 900 zł netto, a strony od 2 990 zł netto.

Źródła

• FIDO Alliance: Passkey Index 2026 (15.10.2026)
• FIDO Alliance: Passkey Index, raport PDF z października 2026
• FIDO Alliance: czym są passkeys
• NCSC: Leave passwords in the past, passkeys are the future (23.04.2026)
• NIST SP 800-63B-4: Syncable Authenticators
• Microsoft: Pushing passkeys forward (1.05.2025)
• passkeys.dev (W3C i FIDO Alliance): obsługa urządzeń, aktualizacja 21.09.2026
• Google: środowiska obsługujące passkeys
• Google: kiedy proponować utworzenie klucza dostępu
• Google: jak mówić użytkownikom o kluczach dostępu
• Google: przewodniki dla programistów (Digital Asset Links)
• Android: passkeys i Credential Manager
• Apple: Supporting passkeys
• Apple WWDC25: What’s new in passkeys
• Apple: App Store Review Guidelines
• Microsoft: tworzenie i zapisywanie klucza dostępu (Windows Hello)
• Supabase: Passkeys for Supabase Auth (Beta), 28.05.2026