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 sleutelproviders. Hierdoor kan een ondersteunende sleutelprovider onjuiste of ingetrokken sleutels bijwerken of verwijderen uit de opslag, zodat gebruikers deze niet langer aangeboden krijgen.

Verenigbaarheid

Chrome ondersteunt Signal API op alle desktopplatforms en Android.

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

Google Wachtwoordmanager kan toegangscodes bijwerken om het signaal te reflecteren. Toegangscodeproviders op basis van Chrome-extensies op desktops bepalen of het signaal wordt gereproduceerd.

Achtergrond

Wanneer een toegangssleutel ( een vindbare referentie ) wordt aangemaakt, worden metagegevens zoals een gebruikersnaam en een weergavenaam samen met de privésleutel opgeslagen bij de toegangssleutelprovider (zoals een wachtwoordbeheerder), terwijl de openbare sleutel wordt opgeslagen op de server van de vertrouwende partij (RP). Door de gebruikersnaam en weergavenaam op te slaan, kunnen gebruikers gemakkelijker identificeren welke aangeboden toegangssleutels ze moeten gebruiken om zich aan te melden wanneer daarom wordt gevraagd. Dit is vooral handig wanneer gebruikers meer dan twee toegangssleutels van verschillende toegangssleutelproviders hebben.

Er zijn echter een paar gevallen waarin inconsistenties tussen de lijst met wachtwoorden van de sleutelprovider en de lijst met inloggegevens van de server voor verwarring kunnen zorgen.

Het eerste geval is wanneer een gebruiker een inloggegevens op de server verwijdert. Hierdoor blijft de toegangssleutel in de toegangssleutelprovider ongewijzigd. De volgende keer dat de gebruiker probeert in te loggen met een toegangssleutel, presenteert de toegangssleutelprovider die toegangssleutel nog steeds aan de gebruiker. De poging om in te loggen mislukt echter omdat de server de verwijderde openbare sleutel niet kan verifiëren.

Het tweede geval is wanneer een gebruiker zijn gebruikersnaam of weergavenaam op de server bijwerkt. De volgende keer dat de gebruiker zich probeert aan te melden, blijft de toegangscode in de toegangscodeprovider de oude gebruikersnaam en weergavenaam weergeven, ook al zijn deze bijgewerkt op de server. Idealiter worden deze gesynchroniseerd.

Signaal API

De Signal API is een WebAuthn API die deze inconsistenties oplost door RP's wijzigingen te laten doorgeven aan de sleutelprovider. Er zijn drie methoden:

Signaal dat een referentie niet 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 credential-ID, kan de RP de sleutelprovider informeren dat de opgegeven referentie is verwijderd of niet bestaat. De sleutelprovider bepaalt hoe dit signaal moet worden verwerkt, maar de bijbehorende sleutel moet worden verwijderd, zodat gebruikers niet proberen in te loggen met een sleutel waaraan geen referentie is gekoppeld.

Browser Support

  • Chroom: 132.
  • Rand: 132.
  • Firefox: niet ondersteund.
  • Safari: 26.

Source

Deze API kan worden aangeroepen wanneer een aanmelding op basis van een wachtwoordsleutel is mislukt omdat een inloggegevens ontbreken . Op deze manier kan de RP voorkomen dat gebruikers proberen in te loggen met een wachtwoordsleutel waaraan geen inloggegevens zijn gekoppeld. In tegenstelling tot signalAllAcceptedCredentials hoeft u bij deze methode niet de volledige lijst met inloggegevens door te geven. Gebruik deze methode daarom wanneer de gebruiker niet is geauthenticeerd om te voorkomen dat het aantal wachtwoordsleutels voor een bepaalde gebruiker wordt onthuld.

Een dialoogvenster dat wordt weergegeven wanneer een toegangssleutel wordt verwijderd uit Google Password Manager in Chrome.
Een dialoogvenster dat wordt weergegeven wanneer een toegangssleutel wordt verwijderd uit Google Password Manager in Chrome.

Geef een lijst met opgeslagen referenties weer 

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

Gebruik PublicKeyCredential.signalAllAcceptedCredentials() nadat een gebruiker zich heeft aangemeld of accountinstellingen heeft beheerd. U verstrekt een lijst met alle geldige inloggegevens voor die gebruiker. De sleutelprovider vergelijkt deze lijst met de lokale opslag van die vertrouwende partij. De sleutelprovider markeert elke sleutel in de opslag die niet is opgenomen in de lijst allAcceptedCredentialIds als "verborgen". Het systeem biedt deze verborgen sleutels niet langer aan voor aanmelden of automatisch invullen, maar ze worden niet onmiddellijk permanent verwijderd, waardoor herstel indien nodig mogelijk is. De sleutelprovider herstelt daarentegen wel sleutels die aanwezig zijn in allAcceptedCredentialIds en die als "verborgen" zijn gemarkeerd. Hierdoor kan uw website sleutels herstellen die per ongeluk verborgen waren.

Browser Support

  • Chroom: 132.
  • Rand: 132.
  • Firefox: niet ondersteund.
  • Safari: 26.

Source

Roep deze API aan wanneer een gebruiker een toegangssleutel verwijdert op de RP en bij elke aanmelding , zodat de toegangssleutelprovider een gesynchroniseerde lijst met toegangssleutels 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 sleutelprovider informeren over de bijgewerkte gebruikersinformatie. De sleutelprovider bepaalt hoe dit signaal moet worden verwerkt, maar moet de sleutels die de gebruiker bezit, bijwerken met de nieuwe gebruikersinformatie.

Browser Support

  • Chroom: 132.
  • Rand: 132.
  • Firefox: niet ondersteund.
  • Safari: 26.

Source

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.

Een dialoogvenster dat wordt weergegeven wanneer de metagegevens van een wachtwoordsleutel worden bijgewerkt in Google Password Manager in Chrome.
Een dialoogvenster dat wordt weergegeven wanneer de metagegevens van een wachtwoordsleutel worden bijgewerkt in Google Password Manager in Chrome.

Samenvatting

De Signal API helpt u een betere wachtwoordervaring te creëren door onverwachte aanmeldingsfouten te voorkomen. Met de Signal API kunnen vertrouwende partijen de lijst met bestaande inloggegevens en hun metadata signaleren, zodat ze de wachtwoorden op de wachtwoordprovider gesynchroniseerd kunnen houden.

Voor meer informatie over wachtwoorden, zie Wachtwoordloos inloggen met wachtwoorden .