Klucz dostępu zamiast hasła: zaprojektuj także dzień po zgubieniu telefonu
Klucz dostępu wymaga więcej niż przycisku logowania. Jak zaprojektować dodanie, rozpoznanie i usunięcie metody oraz powrót po utracie urządzenia?

W tym artykule
W poniedziałek logowanie trwało chwilę. W środę telefon został w pociągu. Portal wciąż proponuje „Zaloguj się kluczem dostępu”, jakby nie zauważył drobnej zmiany w wyposażeniu pasażera. Obietnica wygody jest teraz sprawdzana w znacznie trudniejszych warunkach niż podczas prezentacji nowego przycisku.
Klucz dostępu, czyli passkey, jest metodą logowania wykorzystującą mechanizmy kryptograficzne zamiast wpisywania hasła do serwisu. Dla użytkownika ważniejsze od nazwy protokołu bywają praktyczne pytania: gdzie ta metoda jest dostępna, jak ją rozpoznać oraz co zrobić, gdy przestanie działać. Projekt powinien objąć jej cały okres używania.
Wyobraźmy sobie fikcyjny portal partnerów drukarni. Marta wraca do zamówień, pobiera zatwierdzone projekty i dopisuje uwagi do kolejnego nakładu. Firma chce ułatwić logowanie, ale nie może pozwolić, żeby przypadkowa osoba przejęła konto po krótkiej rozmowie z obsługą. Wygodny ekran i zasady potwierdzania dostępu muszą zostać zaprojektowane razem, choć odpowiadają za nie różne części zespołu.
Klucz nie musi oznaczać jednego telefonu
FIDO Alliance rozróżnia klucze synchronizowane i powiązane z konkretnym urządzeniem. Dostawca kluczy może udostępniać je na kolejnych zgodnych urządzeniach; nie każdy klucz ma jednak taki sam sposób przenoszenia.
Ta różnica wpływa na nazwy widoczne w portalu. Etykieta „Telefon Marty” może wprowadzać w błąd, jeśli metoda jest dostępna przez menedżer synchronizujący klucze także na jej komputerze. Z kolei ogólne „Klucz dostępu” nie pomoże odróżnić kilku metod. Nazwa powinna ułatwiać rozpoznanie tego, co użytkownik faktycznie posiada, bez zgadywania na podstawie pojedynczej informacji o urządzeniu.
Nie obiecuj więc „zalogujesz się z każdego telefonu”. Zapisz wspierany wariant oraz to, czego wymaga od użytkownika. Marta może korzystać z innego dostawcy kluczy niż członek jej zespołu. Zmiana telefonu może oznaczać przywrócenie dostępu przez tego samego dostawcę albo potrzebę innej, wcześniej przygotowanej metody. To nie jest jedna uniwersalna instrukcja wymiany urządzenia.
Dobrze jest pokazać korzyść przy czynności, do której pasuje: „Dodaj klucz dostępu, aby logować się bez wpisywania hasła”. Dalsze wyjaśnienie ma odpowiadać używanemu rozwiązaniu. Jeżeli system nie pozwala wiarygodnie wskazać dostawcy lub synchronizacji, ekran nie powinien dopisywać takiej pewności. Projektant może przygotować czytelny wariant dla informacji nieznanej.
Dodanie metody musi skończyć się rozpoznawalnym wynikiem
Marta jest już zalogowana do drukarni i otwiera ustawienia dostępu. Zanim zobaczy okno urządzenia, powinna wiedzieć, do którego konta dodaje metodę. Nazwa firmy i adres używany w portalu pomagają uniknąć pomyłki, zwłaszcza gdy obsługuje kilka marek. Nie wystarczy ogólny nagłówek „Zabezpiecz swoje konto”, wyświetlany tak samo w każdej przestrzeni.
Dalej rozpoczyna tworzenie klucza. Strona powinna przygotować ją na przejście do systemowego przebiegu bez odtwarzania go jako własnej, mylącej imitacji. Po powrocie potrzebne jest potwierdzenie związane z rzeczywistym zapisem metody. Samo zamknięcie okna nie rozstrzyga, czy Marta je anulowała, zakończyła poprawnie czy napotkała problem.
W przypadku rezygnacji nie musi tracić wcześniejszego dostępu do portalu. Można krótko powiedzieć, że nowa metoda nie została dodana, i pozostawić ustawienia w poprzednim stanie. Błąd powinien pozwolić ponowić odpowiednią czynność albo użyć innej obsługiwanej drogi. Nie każ od razu zakładać drugiego konta do tych samych zamówień.
Po dodaniu pokaż metodę w miejscu, do którego da się wrócić później. Marta nie powinna pamiętać, czy przycisk zarządzania był schowany na stronie powitalnej, w oknie promocji czy w wiadomości po logowaniu. Ustawienia dostępu potrzebują stałej, rozpoznawalnej drogi z konta. Pierwsze użycie narzędzia może wyjaśnić funkcję, lecz nie zastępuje późniejszego zarządzania.
Dodawanie klucza nie powinno też przypadkowo zmieniać modelu zakupu. Jeśli sklep oferuje zamówienie bez konta, nowa metoda logowania nie jest powodem, by nagle wymuszać rejestrację przy kasie. Najpierw trzeba ustalić, do jakiego konta i zadania odnosi się proponowane ułatwienie. W naszym portalu partnerka już posiada konto z historią projektów.
Oddziel w komunikatach konto drukarni od konta dostawcy kluczy. Adres użyty w menedżerze nie musi być nazwą, pod którą Marta pracuje w portalu. Przy tworzeniu i późniejszym logowaniu pokaż właściwe oznaczenie konta drukarni. Jeżeli system wybiera inną z dostępnych tożsamości, użytkowniczka powinna zobaczyć ten wybór przed wejściem do zamówień. Sam znajomy dostawca nie wyjaśnia jeszcze, do którego firmowego profilu prowadzi dana metoda.
Lista metod ma pomagać przy decyzji „usuń”
Przygotuj listę, na której da się odróżnić metody. Rozpoznawalna nazwa, dostępna informacja o dostawcy i daty mogą pomóc Marcie wskazać właściwą pozycję. Nie pokazuj jednak domniemanego miejsca logowania jako pewnego adresu osoby. Zestaw informacji powinien wynikać z danych systemu oraz potrzeb decyzji, nie z chęci zapełnienia wiersza tabeli.
Przewodnik web.dev o zarządzaniu kluczami opisuje listę metod, możliwość dodania kolejnych oraz ostrzeżenie przed usunięciem ostatniej użytecznej drogi logowania. Wskazuje też różnicę między usunięciem wpisu serwera a kopią u dostawcy.
W drukarni Marta widzi dwie metody i chce usunąć starą. Potwierdzenie powinno wskazywać konkretną pozycję oraz skutek dla kolejnego wejścia. Pytanie „Czy na pewno?” bez nazwy zmusza do pamiętania, który przycisk został właśnie wybrany. Jeżeli można zmienić nazwę, upewnij się, że późniejsze komunikaty korzystają z tej samej aktualnej etykiety.
Gdy to ostatnia metoda, treść musi powiedzieć, jak Marta zaloguje się następnym razem. Samo słowo „ostatnia” jest za mało konkretne: ostatni klucz nie musi być ostatnim sposobem dostępu, jeżeli istnieje inna działająca metoda. Z drugiej strony widoczne pole e-maila nie dowodzi, że portal oferuje logowanie przez pocztę. Projekt powinien odwoływać się do faktycznej konfiguracji danego konta.

Można zaproponować dodanie innej metody przed usunięciem, jeśli produkt to obsługuje. Nie warto traktować każdej istniejącej pozycji jako wystarczającego zabezpieczenia ciągłości. Marta może nie mieć już drugiego urządzenia albo dostępu do konta dostawcy. Rozpoznanie wpisu na liście i praktyczna możliwość użycia metody to dwie różne informacje.
Web.dev opisuje również sytuację, w której wpis usunięto z serwera, ale dostawca nadal go proponuje. Logowanie tym kluczem zakończy się niepowodzeniem. Uzgodnienie obu list zależy od obsługiwanych mechanizmów; samo zniknięcie wiersza w portalu nie potwierdza usunięcia każdej kopii.
Marta potrzebuje wtedy instrukcji dotyczącej konkretnej metody. Nie powinna próbować odzyskiwać całego konta tylko dlatego, że widzi nieaktualną propozycję w oknie logowania. Przy odbiorze zapisz także los istniejących sesji po usunięciu klucza. Jeśli produkt ma kończyć dostęp na innych urządzeniach, wymaga to własnej decyzji i sprawdzenia. Usunięcie metody oraz zakończenie wcześniej otwartej pracy nie powinny mieć jednej niejasnej etykiety.
Telefon zniknął. Co jeszcze jest dostępne?
W środę Marta otwiera portal na komputerze. Jeśli ma tam działającą metodę, utrata telefonu nie musi oznaczać utraty całego konta. Powinna móc rozpoznać dostępną drogę i następnie uporządkować ustawienia. Zanim skierujesz ją do procedury odzyskiwania, odróżnij brak jednej metody od utraty wszystkich dostępnych sposobów logowania.
Jeżeli klucz może wrócić przez używanego dostawcę, instrukcja musi odnosić się do tego dostawcy i właściwego konta. Portal drukarni nie powinien udawać, że zarządza kontem usługi przechowującej klucze. Własna pomoc może wyjaśnić granicę i prowadzić do odpowiedniej oficjalnej instrukcji. Nie wolno natomiast zbierać w firmowym formularzu danych, których drukarnia nie potrzebuje do swojej procedury.
Trudniejszy wariant zaczyna się, gdy Marta nie ma żadnej działającej metody. Wtedy potrzebny jest rzeczywisty proces odzyskania konta, z warunkami ustalonymi przez osoby odpowiedzialne za bezpieczeństwo. Projekt nie powinien wymyślać, że wystarczy nowy adres e-mail albo numer ostatniego zamówienia. Prosta instrukcja nie dowodzi, że procedura rozpoznaje właściciela wystarczająco pewnie.
NIST w części o zdarzeniach dotyczących metod potwierdzania dostępu odróżnia odzyskanie konta od zwykłego logowania i opisuje, że procedura może być mniej wygodna oraz wymagać oczekiwania. To techniczny punkt odniesienia, nie automatyczny obowiązek dla każdego portalu.
W naszym projekcie klient powinien dowiedzieć się, którą obsługiwaną drogę uruchamia, jaki jest obecny etap i gdzie otrzyma dalszą informację. Jeżeli firma nie potwierdza czasu zakończenia, nie wpisuj obietnicy „dostęp za pięć minut”. Kiedy potrzebne jest działanie obsługi, pokaż właściwy kontakt oraz zakres materiału do przygotowania. Nie zachęcaj do wysyłania dowolnego kompletu dokumentów na ogólną skrzynkę.
Jeśli zgłoszenie odzyskania zostało już przyjęte, pokaż sposób odnalezienia jego stanu. Ponowne wejście na stronę pomocy nie powinno wyglądać jak konieczność rozpoczęcia od nowa. W fikcyjnym portalu można wskazać numer sprawy i ustalony kanał dalszego kontaktu. Do próby dołącz ponowne otwarcie instrukcji przed odpowiedzią obsługi. Marta ma rozpoznać, czy czeka na tę samą sprawę i czy firma wymaga od niej kolejnego działania.
Przy odzyskaniu trzeba również powiązać wynik z właściwym kontem. Marta chce wrócić do historii zamówień, a nie otrzymać nowy pusty profil o podobnej nazwie. Po zakończeniu procedury interfejs powinien umożliwiać rozpoznanie miejsca, do którego trafiła. Szczegóły przyznania dostępu oraz unieważnienia wcześniejszych metod wymagają osobnego odbioru technicznego; sam napis „Odzyskano” ich nie potwierdza.
Zalogowana karta nie dowodzi, że nowa metoda działa
Podczas odbioru łatwo przegapić ten problem. Projektant dodaje klucz, nadal widzi portal i uznaje próbę za zakończoną. Tymczasem otwarta karta korzysta z wcześniej uzyskanej sesji. Nową metodę trzeba sprawdzić przy ponownym wejściu, które rzeczywiście wymaga logowania. W próbie korzystaj z przygotowanego konta, dla którego istnieje uzgodniona droga powrotu.
Nie zaczynaj eksperymentów od usunięcia jedynej metody na koncie z prawdziwymi zamówieniami. Materiał próbny pozwala bezpiecznie porównać stany: anulowanie dodawania, zapis, powrót do logowania oraz usunięcie wskazanej pozycji. Dla każdego przypadku zapisz oczekiwany wynik przed próbą. Nie uznawaj obecności wiersza na liście za sprawdzenie całego dostępu.
Osobno przejdź wygaśnięcie sesji podczas pracy. Marta może mieć otwartą uwagę do projektu, kiedy portal poprosi o potwierdzenie dostępu. Udane logowanie powinno przywrócić właściwy cel bez tworzenia drugiej uwagi. Zarządzanie kluczami i zachowanie rozpoczętej pracy spotykają się właśnie w tym momencie.
Ustawienia nie kończą się na tym urządzeniu
Na wspólnym terminalu pojawia się inna granica. Użytkownik nie powinien przez przypadek skonfigurować długotrwałego dostępu do własnego konta na urządzeniu należącym do miejsca obsługi. Jeśli produkt obsługuje taki kontekst, projekt musi go uwzględniać w propozycjach oraz zakończeniu wizyty. Ikona telefonu narysowana przy przycisku nie rozwiązuje tego problemu.
Również instalacja aplikacji internetowej nie oznacza automatycznie zapisania nowej metody logowania. Po uruchomieniu z ikony nadal trzeba rozpoznać konto oraz dostępny przebieg. Nie łącz potwierdzenia instalacji z komunikatem o gotowości klucza, jeśli system nie potwierdził obu zdarzeń osobno.
Przed oddaniem projektu zbierz pytania obsługi. Co powie osobie z nowym telefonem? Jak skieruje kogoś, kto ma inną działającą metodę? Jak odróżni prośbę o usunięcie starej pozycji od zgłoszenia utraty wszystkich sposobów dostępu? Odpowiedzi powinny zgadzać się z ekranami, a nie powstawać dopiero podczas pierwszej trudnej rozmowy.
W Aeneia Design można przygotować projekt tej drogi wraz z komunikatami i przypadkami odbioru. Zespół odpowiedzialny za uwierzytelnienie określa dopuszczone mechanizmy oraz zasady odzyskiwania. Dzięki temu Marta widzi uczciwą instrukcję także w środę, gdy telefon nadal jedzie pociągiem, a portal potrzebuje rozpoznać jej prawo do pracy z zamówieniami.

