Safari, system i 1Password chcą obsłużyć ten sam passkey: konflikt menedżerów poświadczeń na jednym urządzeniu

Passkey potrafi uprościć logowanie do jednego dotknięcia Touch ID albo potwierdzenia Face ID. Problem zaczyna się chwilę wcześniej: podczas tworzenia poświadczenia Safari, systemowy menedżer Passwords i 1Password mogą uczestniczyć w tym samym procesie, a użytkownik często nie zwraca uwagi, gdzie ostatecznie trafił klucz. Kilka tygodni później logowanie działa na iPhonie, ale nie działa na komputerze z Windowsem, albo Safari proponuje inne konto niż 1Password. Technicznie nic nie musi być zepsute. Po prostu poświadczenia zostały zapisane u różnych dostawców.

To szczególnie łatwo przeoczyć na nowych wersjach systemów Apple. Od iOS 18 i macOS Sequoia Apple ma osobną aplikację Passwords, a w macOS Tahoe 26 i iOS 26 obsługa poświadczeń oraz ich przenoszenia jest jeszcze mocniej zintegrowana z systemem. Jednocześnie 1Password potrafi działać jako dostawca AutoFill i przechowywać passkeys. Od sierpnia 2026 r. 1Password 8 na Macu może dodatkowo korzystać z natywnego mechanizmu macOS AutoFill, więc granica między „podpowiedzią Safari” a „podpowiedzią 1Password” jest dla użytkownika jeszcze mniej widoczna.

Safari nie przechowuje trzeciej kopii passkey. Konflikt powstaje gdzie indziej

Pierwsza rzecz, którą trzeba uporządkować: Safari nie jest osobnym sejfem passkeys konkurującym z Passwords i 1Password. Safari obsługuje żądanie WebAuthn wysyłane przez stronę i przekazuje je do mechanizmów uwierzytelniania systemu. Dopiero wtedy wybierany jest dostawca poświadczenia.

W praktyce na Macu lub iPhonie mogą być dostępne co najmniej dwa źródła:

• Passwords / iCloud Keychain – systemowy magazyn Apple synchronizowany przez iCloud;
• 1Password – zewnętrzny menedżer działający jako credential provider;
• dodatkowo urządzenie może zaproponować klucz sprzętowy albo użycie passkey z innego urządzenia, np. telefonu znajdującego się w pobliżu.

Sam passkey nie jest hasłem kopiowanym do formularza. Podczas rejestracji powstaje para kluczy kryptograficznych. Klucz prywatny pozostaje u dostawcy poświadczenia, a serwis internetowy dostaje klucz publiczny wraz z identyfikatorem poświadczenia. Przy kolejnym logowaniu serwer wysyła wyzwanie kryptograficzne, które musi zostać podpisane właściwym kluczem prywatnym.

To tłumaczy typowy scenariusz z praktyki. Użytkownik tworzy passkey do GitHuba w Safari i zapisuje go w Passwords. Tydzień później na innym koncie GitHuba dodaje drugi passkey, ale tym razem wybiera okno 1Password. Oba logowania działają. Problem pojawia się dopiero na komputerze, na którym dostępny jest tylko jeden z tych magazynów.

Jeszcze bardziej myląca jest sytuacja, gdy jeden serwis ma więcej niż jeden passkey dla tego samego konta. To nie musi być błąd. GitHub, Google czy inne usługi mogą pozwalać na zarejestrowanie kilku poświadczeń: jednego w iCloud Keychain, drugiego w 1Password, trzeciego na kluczu YubiKey. Każde jest osobnym credentialem.

Bałagan zaczyna się wtedy, gdy użytkownik nie wie, które z nich jest jego podstawową metodą logowania.

Dlatego przy diagnozowaniu problemu nie należy zaczynać od kasowania wszystkiego. Najpierw trzeba odpowiedzieć na trzy pytania:

1. W którym menedżerze znajduje się passkey?
2. Czy serwis ma zapisanych kilka passkeys dla tego samego konta?
3. Czy urządzenie, na którym logowanie nie działa, ma dostęp do tego samego dostawcy poświadczeń?

Kasowanie passkey „na próbę” jest kiepskim pierwszym ruchem. Jeśli konto nie ma alternatywnej metody odzyskiwania, można sobie w ten sposób niepotrzebnie utrudnić dostęp.

Najwięcej problemów powstaje podczas zapisywania, nie podczas logowania

Podczas logowania konflikt jest widoczny: system pokazuje kilka możliwości i użytkownik wybiera jedną. Przy tworzeniu passkey problem jest mniej oczywisty, ponieważ decyzja o miejscu zapisania poświadczenia często wygląda jak rutynowe okno systemowe.

Na urządzeniu Apple mogą nakładać się trzy warstwy interfejsu:

• formularz i komunikaty strony otwartej w Safari;
• okno Authentication Services wyświetlane przez macOS lub iOS;
• interfejs lub rozszerzenie 1Password.

Użytkownik widzi więc komunikaty typu „Utwórz passkey”, „Zapisz w 1Password” albo propozycję systemowego Passwords. Jeśli wszystkie mechanizmy są włączone, wystarczą dwa szybkie kliknięcia, aby nowe poświadczenie wylądowało w innym miejscu niż poprzednie.

Najbardziej irytujący efekt pojawia się w środowisku mieszanym: Mac + iPhone + komputer służbowy z Windowsem albo Androidem. iCloud Keychain jest świetnie zintegrowany z urządzeniami Apple, natomiast 1Password jest projektowany jako rozwiązanie wieloplatformowe. Jeżeli ktoś regularnie pracuje na Windowsie, Linuksie i Androidzie, przypadkowe zapisanie części passkeys wyłącznie w magazynie Apple oznacza dodatkowe kombinowanie podczas logowania.

Odwrotna sytuacja również występuje. Osoba korzystająca wyłącznie z Maca, iPhone'a i iPada może mieć niewielki praktyczny powód, aby płacić za drugi magazyn tylko po to, żeby przechowywać passkeys. Aplikacja Passwords jest elementem systemu Apple i nie wymaga osobnego abonamentu.

1Password kosztuje obecnie w planie indywidualnym 2,99 USD miesięcznie przy rozliczeniu rocznym albo 3,99 USD przy płatności miesięcznej. Plan Families kosztuje odpowiednio 4,49 USD albo 5,99 USD miesięcznie i obejmuje do pięciu członków rodziny. Konta zakładane w regionie europejskim są rozliczane w euro, a dane konta mogą być przechowywane w regionie UE. Dla kogoś pracującego na kilku systemach operacyjnych abonament ma więc konkretną wartość. Przy środowisku wyłącznie Apple argument jest słabszy.

Osobnym źródłem zamieszania są dwa mechanizmy 1Password na Macu. Program może współpracować z rozszerzeniem przeglądarki, a obecne wydania 1Password 8 obsługują również natywny macOS AutoFill. W efekcie użytkownik może mieć aktywną integrację systemową i dodatkowo rozszerzenie Safari. Nie oznacza to dwóch sejfów 1Password, ale może oznaczać więcej komunikatów, ikon i propozycji na jednej stronie.

Jeżeli Safari podczas logowania regularnie pokazuje zbyt dużo podpowiedzi, nie należy zaczynać od wyłączania całego AutoFill. Lepsza kolejność to:

• wybrać jeden podstawowy magazyn passkeys;
• sprawdzić, którzy dostawcy poświadczeń są aktywni w ustawieniach AutoFill systemu;
• dopiero później zdecydować, czy rozszerzenie przeglądarki nadal jest potrzebne do pozostałych funkcji 1Password.

W 1Password można też wyłączyć samo proponowanie zapisywania i używania passkeys, pozostawiając menedżer do haseł, kodów jednorazowych i innych danych. To rozsądne rozwiązanie dla osoby, która chce trzymać passkeys w Apple Passwords, ale pozostałe wpisy nadal przechowuje w 1Password.

Jeden magazyn jako domyślny jest lepszy niż trzy okna wyboru

Najpraktyczniejsza konfiguracja nie polega na usuwaniu wszystkich pozostałych możliwości uwierzytelnienia. Chodzi o ustalenie jednego domyślnego miejsca zapisywania nowych passkeys.

Dla osoby korzystającej praktycznie wyłącznie z urządzeń Apple sensownym punktem wyjścia jest Passwords i iCloud Keychain. Passkeys synchronizują się pomiędzy urządzeniami przypisanymi do tego samego Apple Account, a dostęp jest zintegrowany z Face ID, Touch ID i systemowym AutoFill.

Jeśli komputer z Windowsem, Android albo kilka przeglądarek spoza ekosystemu Apple są częścią codziennej pracy, 1Password ma przewagę organizacyjną. Ten sam sejf można wykorzystywać na różnych platformach, zamiast pamiętać, że część kont ma passkey „w Apple”, a część „w 1Password”.

Są jednak dwa ograniczenia, których nie należy ignorować.

Pierwsze dotyczy migracji. Stary sposób eksportowania haseł przez CSV nie rozwiązuje problemu passkeys. Passkey nie jest zwykłym polem, które da się bezpiecznie wkleić do pliku CSV. Klasyczny eksport Safari do 1Password przenosił hasła, ale nie przenosił passkeys.

Sytuacja poprawiła się w iOS i iPadOS 26 dzięki mechanizmowi Credential Exchange. Obsługujące go menedżery mogą przekazywać między sobą również passkeys. 1Password pozwala obecnie na iPhonie i iPadzie eksportować passkeys przez ten mechanizm oraz importować dane bezpośrednio z kompatybilnych aplikacji, w tym z Passwords.

Nie należy jednak zakładać, że każda ścieżka migracji działa identycznie na każdym urządzeniu. W 1Password eksport passkeys jest obecnie dostępny na iOS i Androidzie, natomiast tradycyjny eksport wykonywany z aplikacji desktopowej nie przenosi ich tak jak Credential Exchange. Przy migracji wykonywanej wyłącznie na Macu może więc nadal być konieczne wejście na konkretną stronę, dodanie nowego passkey w docelowym menedżerze, sprawdzenie logowania i dopiero później usunięcie starego.

Drugie ograniczenie dotyczy samego serwisu. Nie każdy portal pozwala łatwo zarejestrować kilka passkeys albo przejrzyście je nazwać. Dlatego migrację trzeba wykonywać konto po koncie, zaczynając od usług, w których istnieje zapasowa metoda dostępu.

Bezpieczna procedura wygląda następująco:

• zaloguj się do serwisu przy działającym starym passkey;
• sprawdź sekcję bezpieczeństwa konta i listę zarejestrowanych passkeys;
• dodaj nowe poświadczenie do wybranego, docelowego menedżera;
• wyloguj się;
• sprawdź nowe logowanie na co najmniej jednym drugim urządzeniu;
• dopiero po udanym teście usuń stare poświadczenie, jeżeli nie chcesz pozostawiać go jako zapasowego.

Nie robiłbym masowego czyszczenia kilkudziesięciu kont jednego wieczoru. Przy passkeys łatwiej kontrolować migrację partiami: najpierw kilka najważniejszych kont, potem usługi mniej krytyczne. Bank, podstawowy e-mail, konto Apple lub Google i główny serwis pracy powinny mieć najwyższy priorytet.

FAQ: passkeys, Safari, Passwords i 1Password

Czy ten sam passkey może być jednocześnie zapisany w Passwords i 1Password?
Nie należy traktować dwóch niezależnie utworzonych wpisów jako „tego samego passkey”. Serwis może mieć dwa passkeys przypisane do tego samego konta — jeden przechowywany przez Apple, drugi przez 1Password — ale kryptograficznie są to osobne poświadczenia z osobnymi kluczami.

Czy włączenie 1Password automatycznie wyłącza Passwords?
Nie. Zewnętrzny credential provider może działać obok mechanizmów systemowych. Dlatego trzeba sprawdzić ustawienia AutoFill i świadomie zdecydować, który dostawca ma być używany jako podstawowy.

Czy mogę korzystać z haseł w 1Password, a passkeys zapisywać tylko w Apple Passwords?
Tak. 1Password pozwala wyłączyć oferowanie zapisywania i logowania za pomocą passkeys bez rezygnowania z całej aplikacji. To przydatna konfiguracja, jeżeli 1Password ma pozostać sejfem haseł, kodów i notatek, a passkeys mają być konsekwentnie przechowywane przez Apple.

Czy usunięcie passkey z aplikacji Passwords usuwa również wpis w 1Password?
Nie. To niezależne magazyny. Jeżeli serwis ma zarejestrowane dwa poświadczenia, usunięcie jednego nie kasuje automatycznie drugiego.

Czy można już przenieść passkeys z Apple Passwords do 1Password?
Na nowych systemach obsługujących Credential Exchange jest to możliwe bez sprowadzania passkey do zwykłego pliku CSV. W iOS i iPadOS 26 1Password obsługuje bezpośredni import z kompatybilnych menedżerów. Przy migracji na komputerze trzeba jednak uważać, bo desktopowy eksport 1Password nadal nie daje identycznej ścieżki przenoszenia passkeys.

Czy lepiej przechowywać dwa passkeys do ważnego konta?
Czasem tak. Dwa niezależne poświadczenia mogą być sensownym zabezpieczeniem, np. passkey w głównym menedżerze oraz sprzętowy klucz bezpieczeństwa przechowywany jako zapasowy. Nie ma natomiast większego sensu tworzenie kilku passkeys w różnych menedżerach tylko dlatego, że każde okno zapisu zostało zaakceptowane bez zastanowienia.

Co sprawdzić, gdy passkey działa na iPhonie, ale nie pojawia się na Macu?
Najpierw sprawdź, gdzie został zapisany. Jeżeli jest w Passwords, zweryfikuj Apple Account i synchronizację Passwords w iCloud. Jeżeli jest w 1Password, sprawdź, czy Mac korzysta z właściwego konta i sejfu oraz czy 1Password jest aktywnym dostawcą AutoFill. Dopiero później diagnozuj Safari.

Pierwsze działanie powinno być więc bardzo konkretne: otwórz ustawienia AutoFill na urządzeniu i ustal jednego domyślnego dostawcę nowych passkeys. Następnie sprawdź trzy najważniejsze konta i zanotuj, gdzie ich poświadczenia faktycznie się znajdują. Dopiero po tym wyłącz zbędne podpowiedzi albo rozpocznij migrację. Najgorszym błędem jest kasowanie „duplikatów”, zanim nowe logowanie zostało sprawdzone na drugim urządzeniu.

Więcej informacji na: https://sajo.pl