Utrzymywanie spójności kluczy dostępu z danymi logowania na serwerze za pomocą interfejsu Signal API

Data publikacji: 12 listopada 2024 r., ostatnia aktualizacja: 29 listopada 2024 r.

Interfejs WebAuthn Signal API umożliwia podmiotom polegającym przekazywanie sygnałów o istniejących danych logowania do połączonych dostawców kluczy dostępu. Dzięki temu dostawca kluczy dostępu może aktualizować lub usuwać nieprawidłowe lub unieważnione klucze dostępu ze swojego magazynu, aby użytkownicy nie mieli już do nich dostępu.

Zgodność

Chrome obsługuje interfejs Signal API na wszystkich platformach komputerowych i Androidzie.

Safari obsługuje tę funkcję, ale nie została ona jeszcze wdrożona. Firefox nie podzielił się jeszcze swoją opinią.

Menedżer haseł Google może aktualizować klucze dostępu, aby odzwierciedlały sygnał. Dostawcy kluczy dostępu opartych na rozszerzeniach Chrome na komputerach decydują, czy uwzględnić sygnał.

Tło

Gdy tworzony jest klucz dostępu (odkrywalne dane logowania), metadane, takie jak nazwa użytkownika i wyświetlana nazwa, są zapisywane u dostawcy klucza dostępu (np. w menedżerze haseł) wraz z kluczem prywatnym, a dane logowania klucza publicznego są zapisywane na serwerze podmiotu polegającego na uwierzytelnianiu. Zapisywanie nazwy użytkownika i wyświetlanej nazwy pomaga użytkownikom określić, których kluczy dostępu użyć do logowania, gdy pojawi się odpowiedni monit. Jest to szczególnie przydatne, gdy użytkownicy mają więcej niż 2 klucze dostępu od różnych dostawców.

W kilku przypadkach niespójności między listą kluczy dostępu dostawcy a listą danych logowania serwera mogą powodować zamieszanie.

Pierwszy przypadek to usunięcie przez użytkownika danych logowania na serwerze. Klucz dostępu pozostanie nienaruszony u dostawcy kluczy dostępu. Gdy użytkownik spróbuje zalogować się przy użyciu klucza dostępu, dostawca klucza dostępu nadal będzie go wyświetlać. Próba zalogowania się nie powiedzie się jednak, ponieważ serwer nie może zweryfikować usuniętego klucza publicznego.

Drugi przypadek to sytuacja, w której użytkownik zaktualizuje swoją nazwę użytkownika lub nazwę wyświetlaną na serwerze. Przy następnej próbie zalogowania się użytkownika klucz dostępu u dostawcy kluczy dostępu nadal będzie wyświetlać starą nazwę użytkownika i nazwę wyświetlaną, mimo że na serwerze zostały one zaktualizowane. Najlepiej, aby były zsynchronizowane.

Signal API

Signal API to interfejs WebAuthn API, który rozwiązuje te niespójności, umożliwiając podmiotom zależnym sygnalizowanie zmian dostawcy kluczy dostępu. Możesz to zrobić na 3 sposoby:

Sygnalizowanie, że dane logowania nie istnieją

const credential = await navigator.credentials.get({ ... });
const payload = credential.toJSON();

const result = await fetch('/login', { ... });

// Detect authentication failure due to lack of the credential
if (result.status === 404) {
  // Feature detection
  if (PublicKeyCredential.signalUnknownCredential) {
    await PublicKeyCredential.signalUnknownCredential({
      rpId: "example.com",
      credentialId: "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA" // base64url encoded credential ID
    });
  } else {
    // Encourage the user to delete the passkey from the password manager nevertheless.
    ...
  }
}

Wywołując PublicKeyCredential.signalUnknownCredential() z identyfikatorem RP i identyfikatorem danych logowania, RP może poinformować dostawcę klucza dostępu, że określone dane logowania zostały usunięte lub nie istnieją. Dostawca klucza dostępu określa, jak obsługiwać ten sygnał, ale powiązany klucz dostępu powinien zostać usunięty, aby użytkownicy nie próbowali logować się za pomocą klucza dostępu, który nie ma powiązanych danych logowania.

Browser Support

  • Chrome: 132.
  • Edge: 132.
  • Firefox: not supported.
  • Safari: 26.

Source

Ten interfejs API można wywołać w przypadku nieudanego logowania za pomocą klucza dostępu z powodu braku danych logowania. Dzięki temu RP może uniemożliwić użytkownikom próby logowania się za pomocą klucza dostępu, który nie ma powiązanych danych logowania. W przeciwieństwie do metody signalAllAcceptedCredentials nie wymaga ona przekazywania całej listy identyfikatorów danych logowania, więc używaj jej, gdy użytkownik nie jest uwierzytelniony, aby uniknąć ujawnienia liczby kluczy dostępu danego użytkownika.

Okno dialogowe wyświetlane po usunięciu klucza dostępu z Menedżera haseł Google w Chrome.
Okno dialogowe wyświetlane po usunięciu klucza dostępu z Menedżera haseł Google w Chrome.

Sygnalizowanie listy zapisanych danych logowania

// After a user deletes a passkey or a user is signed in.

// Feature detection
if (PublicKeyCredential.signalAllAcceptedCredentials) {
  await PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "M2YPl-KGnA8", // base64url encoded user ID
    allAcceptedCredentialIds: [ // A list of base64url encoded credential IDs
      "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA",
      ...
    ]
  });
}

Używaj PublicKeyCredential.signalAllAcceptedCredentials() po zalogowaniu się użytkownika lub zmianie ustawień konta. Podajesz listę wszystkich prawidłowych identyfikatorów danych logowania użytkownika. Dostawca klucza dostępu porównuje tę listę z lokalnym miejscem na dane tej strony. Dostawca klucza dostępu oznacza jako „ukryty” każdy klucz dostępu znaleziony w jego pamięci, który nie jest uwzględniony na liście allAcceptedCredentialIds. System nie oferuje już tych ukrytych kluczy dostępu do logowania ani autouzupełniania, ale nie są one od razu trwale usuwane, co umożliwia ich przywrócenie w razie potrzeby. Z kolei dostawca kluczy dostępu przywraca klucze dostępu w allAcceptedCredentialIds, które są oznaczone jako „ukryte”. Dzięki temu Twoja witryna może przywrócić klucze dostępu, które zostały omyłkowo ukryte.

Browser Support

  • Chrome: 132.
  • Edge: 132.
  • Firefox: not supported.
  • Safari: 26.

Source

Wywołuj ten interfejs API gdy użytkownik usunie klucz dostępu w RP i przy każdym logowaniu, aby dostawca kluczy dostępu mógł utrzymywać zsynchronizowaną listę kluczy dostępu.

Sygnał zaktualizował nazwę użytkownika i wyświetlaną nazwę

// After a user updated their username and/or display name
// or a user is signed in.

// Feature detection
if (PublicKeyCredential.signalCurrentUserDetails) {
  await PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "M2YPl-KGnA8", // base64url encoded user ID
    name: "a.new.email.address@example.com", // username
    displayName: "J. Doe"
  });
} else {
}

Wywołując funkcję PublicKeyCredential.signalCurrentUserDetails() z identyfikatorem RP, identyfikatorem użytkownika, nazwą użytkownika i wyświetlaną nazwą, RP może poinformować dostawcę klucza dostępu o zaktualizowanych informacjach o użytkowniku. Dostawca kluczy dostępu określa, jak obsługiwać ten sygnał, ale powinien zaktualizować klucze dostępu należące do użytkownika, aby uwzględnić nowe informacje o użytkowniku.

Browser Support

  • Chrome: 132.
  • Edge: 132.
  • Firefox: not supported.
  • Safari: 26.

Source

Ten interfejs API można wywoływać po zaktualizowaniu nazwy użytkownika lub nazwy wyświetlanej oraz przy każdym logowaniu, aby dostawca klucza dostępu mógł utrzymywać te informacje w synchronizacji z serwerem.

Okno dialogowe wyświetlane, gdy metadane klucza dostępu są aktualizowane w Menedżerze haseł Google w Chrome.
Okno dialogowe wyświetlane po zaktualizowaniu metadanych klucza dostępu w Menedżerze haseł Google w Chrome.

Podsumowanie

Interfejs Signal API pomaga ulepszyć obsługę kluczy dostępu, eliminując nieoczekiwane błędy logowania. Interfejs Signal API umożliwia podmiotom polegającym na uwierzytelnianiu przekazywanie listy istniejących danych logowania i ich metadanych, dzięki czemu mogą one synchronizować klucze dostępu z dostawcą kluczy dostępu.

Więcej informacji o kluczach dostępu znajdziesz w artykule Logowanie bez hasła za pomocą kluczy dostępu.