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. Hiermee kan een ondersteunende sleutelprovider onjuiste of ingetrokken sleutels 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 Password Manager kan toegangssleutels bijwerken op basis van het signaal. Voor aanbieders van toegangssleutels op basis van Chrome-extensies is het aan hen om te bepalen of ze het signaal wel of niet reflecteren.

Ondersteuning voor Chrome op Android volgt later.

Safari ondersteunt het, maar is nog niet geïmplementeerd. Firefox heeft nog geen mening gegeven .

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, kan de gebruiker gemakkelijker identificeren met welke van de aangeboden toegangssleutels hij/zij zich moet aanmelden wanneer daarom wordt gevraagd. Dit is vooral handig wanneer er meer dan twee toegangssleutels van verschillende toegangssleutelproviders zijn.

Er zijn echter een aantal gevallen bekend waarin inconsistenties tussen de lijst met wachtwoorden van de sleutelprovider 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 toegangssleutelprovider ongewijzigd laat. De volgende keer dat de gebruiker probeert in te loggen met een toegangssleutel, wordt die toegangssleutel nog steeds door de toegangssleutelprovider aan de gebruiker gepresenteerd. De poging om in te loggen mislukt echter omdat de server niet kan verifiëren met de verwijderde openbare sleutel.

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

Signaal API

De Signal API is een WebAuthn API die deze verwarring oplost door RP's in staat te stellen wijzigingen aan de sleutelprovider door te geven. 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

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. Het is aan de sleutelprovider hoe met dit signaal wordt omgegaan, maar de bijbehorende sleutel wordt naar verwachting verwijderd, zodat de gebruiker zich niet met een sleutel kan aanmelden omdat de bijbehorende referentie niet bestaat.

Deze API kan worden aangeroepen wanneer een aanmelding 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 wachtwoordsleutel waaraan geen inloggegevens zijn gekoppeld. In tegenstelling tot signalAllAcceptedCredentials hoeft bij deze methode niet de volledige lijst met inloggegevens te worden doorgegeven. Deze methode moet daarom worden gebruikt wanneer de gebruiker niet is geauthenticeerd om te voorkomen dat het aantal wachtwoordsleutels voor een bepaalde gebruiker wordt onthuld.

Geef een lijst met opgeslagen inloggegevens 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",
      ...
    ]
  });
}

Door PublicKeyCredential.signalAllAcceptedCredentials() aan te roepen met een RP-ID, een gebruikers-ID en een lijst met opgeslagen referentie-ID's, kan de RP de sleutelprovider informeren over de resterende referenties in zijn opslag. Het is aan de sleutelprovider hoe met dit signaal om te gaan, maar de sleutelproviders die niet aan deze lijst voldoen, worden naar verwachting verwijderd, zodat de gebruiker bij het aanmelden geen sleutel ziet waarvoor de bijbehorende referentie niet bestaat.

Deze API moet worden aangeroepen 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. Het is aan de sleutelprovider hoe met dit signaal om te gaan, maar de sleutels die de gebruiker bezit, worden naar verwachting 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 sleutelprovider deze informatie gesynchroniseerd kan houden met de server.

Samenvatting

De Signal API helpt u een betere wachtwoordervaring te creëren door de kans op onverwachte mislukte aanmeldingen te elimineren. Met de Signal API kunnen vertrouwende partijen de lijst met bestaande inloggegevens en hun metadata signaleren, zodat ze de wachtwoorden van de wachtwoordprovider synchroon kunnen houden.

Wilt u meer weten over wachtwoordsleutels, begin dan bij Wachtwoordloos inloggen met wachtwoordsleutels .