Houd de toegangscodes consistent met de inloggegevens op uw server met de Signal API

Eiji Kitamura

Gepubliceerd: 12 november 2024, Laatst bijgewerkt: 29 november 2024

Met de WebAuthn Signal API kunnen vertrouwende partijen bestaande inloggegevens doorgeven aan aangesloten wachtwoordproviders. Hiermee kan een ondersteunende toegangscodeprovider onjuiste of ingetrokken toegangscodes bijwerken of verwijderen uit zijn opslag, zodat deze niet langer aan gebruikers worden aangeboden.

Verenigbaarheid

Chrome op desktop ondersteunt de Signal API vanaf Chrome 132. Google Wachtwoordmanager kan toegangscodes bijwerken die het signaal weerspiegelen. Voor aanbieders van op Chrome-extensies gebaseerde wachtwoordsleutels is het aan hen of ze het signaal wel of niet weerspiegelen.

Ondersteuning voor Chrome op Android komt later.

Safari ondersteunt, maar is nog niet geïmplementeerd. Firefox heeft hun mening nog niet gedeeld .

Achtergrond

Wanneer een toegangssleutel ( een vindbare inloggegevens ) wordt aangemaakt, worden metagegevens zoals een gebruikersnaam en een weergavenaam samen met de privésleutel opgeslagen bij de aanbieder van de toegangssleutel (zoals een wachtwoordbeheerder), terwijl de inloggegevens voor de openbare sleutel worden opgeslagen in de database van de vertrouwende partij. (RP's)-server. Door de gebruikersnaam en weergavenaam op te slaan, kan de gebruiker bepalen met welke van de aangeboden toegangscodes hij moet inloggen wanneer daarom wordt gevraagd. Dit is vooral handig als ze meer dan twee wachtwoordsleutels van verschillende sleutelproviders hebben.

Er zijn echter een aantal gevallen waarin inconsistenties tussen de wachtwoordsleutellijst van de leverancier van de sleutel en de lijst met inloggegevens van de server tot verwarring kunnen leiden.

Het eerste geval is wanneer een gebruiker een inloggegevens op de server verwijdert en de toegangssleutel in de toegangscodeprovider onaangeroerd laat. De volgende keer dat de gebruiker zich probeert aan te melden met een toegangssleutel, wordt die toegangssleutel nog steeds aan de gebruiker gepresenteerd door de toegangscodeprovider. De poging om in te loggen mislukt echter omdat de server niet kan verifiëren met de openbare sleutel die is verwijderd.

Het tweede geval is wanneer een gebruiker zijn gebruikersnaam of de weergavenaam op de server bijwerkt. De volgende keer dat de gebruiker zich probeert aan te melden, blijft de toegangssleutel in de toegangscodeprovider de oude gebruikersnaam en weergavenaam weergeven, ondanks dat deze op de server zijn bijgewerkt. Idealiter zouden ze synchroon moeten zijn.

Signaal-API

De Signal API is een WebAuthn API die deze verwarring oplost door RP's in staat te stellen wijzigingen door te geven aan de toegangscodeprovider. Er zijn drie methoden:

• PublicKeyCredential.signalUnknownCredential : Signaal dat een referentie niet bestaat
• PublicKeyCredential.signalAllAcceptedCredentials : signaleer een lijst met opgeslagen referenties
• PublicKeyCredential.signalCurrentUserDetails : Signaal bijgewerkte gebruikersnaam en/of weergavenaam

Geef aan dat er geen referentie bestaat

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.
    ...
  }
}

Door PublicKeyCredential.signalUnknownCredential() aan te roepen met een RP-ID en een inlog-ID, kan de RP de toegangssleutelprovider informeren dat de opgegeven inloggegevens zijn verwijderd of niet bestaan. Het is aan de leverancier van de toegangscode hoe met dit signaal om te gaan, maar de bijbehorende toegangscode wordt naar verwachting verwijderd, zodat de gebruiker zich niet aanmeldt met een toegangscode, omdat de bijbehorende inloggegevens niet bestaan.

Deze API kan worden aangeroepen wanneer inloggen op basis van een wachtwoordsleutel is mislukt vanwege het ontbreken van een inloggegevens . Op deze manier kan de RP voorkomen dat de gebruiker probeert in te loggen met een toegangssleutel waaraan geen bijbehorende referentie is gekoppeld. In tegenstelling tot signalAllAcceptedCredentials vereist deze methode niet dat de volledige lijst met identificatie-ID's wordt doorgegeven. Daarom moet deze worden gebruikt wanneer de gebruiker niet is geverifieerd om te voorkomen dat het aantal wachtwoordsleutels voor een bepaalde gebruiker wordt onthuld.

Signaleer een lijst met opgeslagen inloggegevens

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

Door PublicKeyCredential.signalAllAcceptedCredentials() aan te roepen met een RP-ID, een gebruikers-ID en een lijst met identificatie-ID's van opgeslagen inloggegevens, kan de RP de wachtwoordsleutelprovider informeren over de resterende inloggegevens in zijn opslag. Het is aan de leverancier van de toegangssleutel hoe om te gaan met dit signaal, maar de toegangscodes die niet overeenkomen met deze lijst zullen naar verwachting worden verwijderd, zodat de gebruiker bij het inloggen geen toegangscodes ziet waarvoor de bijbehorende inloggegevens niet bestaan.

Deze API moet worden aangeroepen wanneer een gebruiker een wachtwoordsleutel op de RP en bij elke aanmelding verwijdert, zodat de wachtwoordsleutelprovider een gesynchroniseerde lijst met wachtwoordsleutels kan bijhouden.

Signaal bijgewerkte gebruikersnaam en weergavenaam

// 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 {
}

Door PublicKeyCredential.signalCurrentUserDetails() aan te roepen met een RP-ID, een gebruikers-ID, een gebruikersnaam en een weergavenaam, kan de RP de wachtwoordsleutelprovider informeren over de bijgewerkte gebruikersinformatie. Het is aan de leverancier van het wachtwoord hoe met dit signaal om te gaan, maar de verwachting is dat de wachtwoordsleutels waarvan de gebruiker eigenaar is, worden bijgewerkt met de nieuwe gebruikersinformatie.

Deze API kan worden aangeroepen wanneer de gebruikersnaam of weergavenaam van de gebruiker wordt bijgewerkt en bij elke aanmelding , zodat de toegangssleutelprovider deze informatie gesynchroniseerd kan houden met de server.

Samenvatting

Met de Signal API kunt u een betere wachtwoordsleutelervaring opbouwen door de kans op onverwachte aanmeldingsfouten te elimineren. Met Signal API kunnen vertrouwende partijen de lijst met bestaande inloggegevens en hun metagegevens signaleren, zodat ze de wachtwoordsleutels van de wachtwoordprovider gesynchroniseerd kunnen houden.

Voor meer informatie over wachtwoordsleutels gaat u naar Wachtwoordloos inloggen met wachtwoordsleutels .