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

Eiji Kitamura

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

Interfejs WebAuthn Signal API umożliwia podmiotom zależnym sygnalizowanie istniejących danych logowania połączonym dostawcom kluczy dostępu. Dzięki temu obsługiwany dostawca kluczy dostępu może aktualizować lub usuwać nieprawidłowe lub unieważnione klucze dostępu ze swojego magazynu, aby nie były już oferowane użytkownikom.

Zgodność

Chrome na komputerze obsługuje interfejs Signal API od wersji 132. Menedżer haseł Google może aktualizować klucze dostępu na podstawie tego sygnału. W przypadku dostawców kluczy dostępu opartych na rozszerzeniach do Chrome to od nich zależy, czy będą uwzględniać ten sygnał.

Obsługa Chrome na Androidzie zostanie wprowadzona w późniejszym terminie.

Safari obsługuje tę funkcję, ale nie jest ona jeszcze wdrożona. Firefox nie podzielił się jeszcze swoimi opiniami.

Tło

Gdy tworzony jest klucz dostępu (odkrywalne dane logowania), metadane takie jak nazwa użytkownika i nazwa wyświetlana 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 (RP). Zapisanie nazwy użytkownika i nazwy wyświetlanej pomaga użytkownikowi zidentyfikować, którego z oferowanych kluczy dostępu użyć do zalogowania się, gdy pojawi się odpowiedni komunikat. Jest to szczególnie przydatne, gdy użytkownik ma więcej niż 2 klucze dostępu od różnych dostawców.

Istnieją jednak 2 przypadki, w których niespójności między listą kluczy dostawcy kluczy dostępu a listą danych logowania serwera mogą prowadzić do nieporozumień.

Pierwszy przypadek to sytuacja, w której użytkownik usuwa dane logowania na serwerze, pozostawiając klucz dostępu w usłudze kluczy dostępu bez zmian. Gdy użytkownik spróbuje zalogować się przy użyciu klucza dostępu, dostawca klucza dostępu nadal będzie mu go wyświetlać. Próba zalogowania się nie powiedzie się jednak, ponieważ serwer nie będzie w stanie przeprowadzić weryfikacji za pomocą 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 zostały one zaktualizowane na serwerze. Najlepiej, aby były zsynchronizowane.

Signal API

Signal API to interfejs WebAuthn API, który rozwiązuje te problemy, umożliwiając RP sygnalizowanie zmian dostawcy kluczy dostępu. Możesz to zrobić na 3 sposoby:

• PublicKeyCredential.signalUnknownCredential: sygnał, że dane logowania nie istnieją.
• PublicKeyCredential.signalAllAcceptedCredentials: sygnalizowanie listy zapisanych danych logowania
• PublicKeyCredential.signalCurrentUserDetails: Signal zaktualizował nazwę użytkownika lub nazwę wyświetlaną

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 funkcję 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ą. To dostawca klucza dostępu decyduje, jak postąpić w przypadku tego sygnału, ale oczekuje się, że powiązany klucz dostępu zostanie usunięty, aby użytkownik nie mógł się zalogować za jego pomocą, ponieważ powiązane dane logowania nie będą już istnieć.

Ten interfejs API można wywołać, gdy logowanie za pomocą klucza dostępu nie powiodło się z powodu braku danych logowania. W ten sposób RP może uniemożliwić użytkownikowi próbę zalogowania się za pomocą klucza dostępu, który nie ma powiązanych danych logowania. W przeciwieństwie do signalAllAcceptedCredentials ta metoda nie wymaga przekazywania całej listy identyfikatorów danych logowania, więc należy jej używać, gdy użytkownik nie jest uwierzytelniony, aby uniknąć ujawnienia liczby kluczy dostępu danego użytkownika.

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",
      ...
    ]
  });
}

Wywołując PublicKeyCredential.signalAllAcceptedCredentials() z identyfikatorem RP, identyfikatorem użytkownika i listą identyfikatorów zapisanych danych logowania, RP może poinformować dostawcę kluczy dostępu o pozostałych danych logowania w swoim magazynie. To dostawca klucza dostępu decyduje, jak postąpić z tym sygnałem, ale klucze dostępu, które nie pasują do tej listy, powinny zostać usunięte, aby użytkownik nie widział podczas logowania kluczy dostępu, dla których nie istnieją powiązane dane logowania.

Ten interfejs API powinien być wywoływany gdy użytkownik usunie klucz dostępu w RP i przy każdym logowaniu, aby dostawca klucza 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. To dostawca klucza dostępu decyduje, jak postąpić z tym sygnałem, ale oczekuje się, że klucze dostępu należące do użytkownika zostaną zaktualizowane o nowe informacje o użytkowniku.

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ł synchronizować te informacje z serwerem.

Podsumowanie

Interfejs Signal API pomaga ulepszyć obsługę kluczy dostępu, eliminując ryzyko nieoczekiwanego niepowodzenia logowania. Za pomocą interfejsu Signal API strony ufające mogą przesyłać listę istniejących danych logowania i ich metadanych, aby klucze dostępu u dostawcy kluczy dostępu były zawsze aktualne.

Więcej informacji o kluczach dostępu znajdziesz w artykule Logowanie bez hasła przy użyciu kluczy dostępu.