Data publikacji: 13 listopada 2024 r.
Od wersji 132 Chrome na komputery (macOS, Windows, Linux i ChromeOS) obsługuje interfejs Signal API, który umożliwia utrzymywanie kluczy dostępu u dostawców kluczy dostępu w zgodności z poświadczeniami klucza publicznego na serwerze strony ufającej.
Gdy tworzysz klucz dostępu (odkrywalne dane logowania), metadane, takie jak nazwa użytkownika i wyświetlana nazwa, są zapisywane w usługodawcy kluczy dostępu (np. w menedżerze haseł) wraz z kluczem prywatnym, a klucz publiczny – na serwerze strony korzystającej (RP). Zapisywanie nazwy użytkownika i nazwy wyświetlanej pomaga użytkownikowi określić, za pomocą którego klucza dostępu ma się zalogować, ponieważ podczas logowania jest proszony o wybranie klucza dostępu. Jest to szczególnie przydatne, gdy użytkownik ma więcej niż 2 klucze od różnych dostawców.
W niektórych przypadkach różnice między listą kluczy dostępu dostawcy kluczy dostępu a listą danych logowania na serwerze mogą jednak wprowadzać zamieszanie.
Pierwszy przypadek to sytuacja, gdy użytkownik usuwa dane logowania na serwerze, nie zmieniając klucza dostępu u dostawcy. Gdy użytkownik następnym razem spróbuje zalogować się przy użyciu klucza dostępu, dostawca kluczy dostępu nadal będzie go wyświetlał. Próba zalogowania się się nie powiedzie, ponieważ serwer nie będzie mógł zweryfikować usuniętego klucza publicznego.
Drugi przypadek to sytuacja, gdy użytkownik zaktualizuje swoją nazwę użytkownika lub nazwę wyświetlaną na serwerze. Gdy użytkownik następnym razem spróbuje się zalogować, klucz dostępu w usługodawcy kluczy dostępu będzie nadal wyświetlać starą nazwę użytkownika i wyświetlaną nazwę, mimo że zostały one zaktualizowane na serwerze. W najlepszym przypadku powinny być zsynchronizowane.
Signal API
Interfejs WebAuthn Signal API pozwala dostawcom usług uwierzytelniania sygnalizować dostawcom kluczy dostępu istniejące dane logowania. Umożliwia to dostawcy kluczy dostępu aktualizowanie lub usuwanie nieprawidłowych lub cofniętych kluczy z magazynu danych, aby były zgodne z serwerem.
Jeśli na przykład użytkownik nie może zalogować się w usługach RP, ponieważ powiązane z nimi dane uwierzytelniające na serwerze RP nie istnieją, usługa RP może użyć interfejsu Signal API, aby zasygnalizować dostawcy kluczy dostępu, że usunięte dane uwierzytelniające nie są już ważne. Dzięki temu dostawca kluczy dostępu może usunąć powiązany klucz dostępu.
Innym przykładem jest sytuacja, gdy użytkownik wchodzi na stronę ustawień RP i usuwa dotychczasowe dane logowania. RP może użyć interfejsu Signal API, aby przekazać dostawcy kluczy dostępu listę dostępnych danych logowania, dzięki czemu dostawca może zachować spójność powiązanych kluczy dostępu.
Może też sygnalizować zaktualizowaną nazwę użytkownika i wyświetlaną nazwę, aby można było zaktualizować metadane klucza dostępu zapisane dla tego samego użytkownika.
Jeśli na przykład użytkownik zaktualizuje swoją nazwę użytkownika lub nazwę wyświetlaną w RP, RP może użyć interfejsu Signal API, aby przekazać zaktualizowane informacje o użytkowniku dostawcy kluczy dostępu. Dzięki temu dostawca kluczy dostępu może zachować spójność informacji o powiązanych kluczach dostępu.
Menedżer haseł Google w wersji na komputery z Chrome obsługuje interfejs Signal AP. W przypadku dostawców kluczy dostępu opartych na rozszerzeniach Chrome to od nich zależy, czy będą odzwierciedlać sygnał.
W przyszłości planujemy wprowadzić obsługę interfejsu Signal API w Chrome na Androida.
Aby dowiedzieć się, jak zintegrować interfejs WebAuthn Signal API, przeczytaj artykuł Utrzymywanie listy kluczy dostępu w zsynchronizowaniu z serwerem za pomocą interfejsu Signal API.