Gepubliceerd: 13 november 2024
Vanaf Chrome 132 ondersteunt Chrome Desktop (macOS, Windows, Linux en ChromeOS) de Signal API, waarmee de toegangssleutels op toegangssleutelproviders consistent kunnen blijven met de openbare sleutelreferenties op de server van de vertrouwende partij.
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). De openbare sleutel wordt opgeslagen op de server van de Relying Party (RP). Het opslaan van de gebruikersnaam en weergavenaam helpt de gebruiker te bepalen met welke toegangssleutel hij zich moet aanmelden, omdat de gebruiker bij het aanmelden wordt gevraagd een toegangssleutel te selecteren. Dit is vooral handig wanneer er meer dan twee toegangssleutels van verschillende toegangssleutelproviders zijn.
Er zijn echter een aantal gevallen waarbij verschillen tussen de sleutellijst op de sleutelprovider en de referentielijst op 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 de toegangssleutel, wordt de toegangssleutel nog steeds door de toegangssleutelprovider aan de gebruiker gepresenteerd. 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 probeert in te loggen, blijft de toegangscode in de toegangscodeprovider de oude gebruikersnaam en weergavenaam weergeven, ook al zijn deze op de server bijgewerkt. Idealiter zouden ze gesynchroniseerd moeten zijn.
Signaal API
Met de WebAuthn Signal API kunnen RP's bestaande inloggegevens doorgeven aan aangesloten sleutelproviders. Dit stelt een ondersteunende sleutelprovider in staat om onjuiste of ingetrokken sleutels bij te werken of te verwijderen uit zijn opslag, zodat deze consistent zijn met de server.
Wanneer een gebruiker zich bijvoorbeeld niet kan aanmelden bij een RP omdat de bijbehorende referenties op de RP-server niet meer bestaan, kan de RP Signal API gebruiken om aan te geven dat de verwijderde referenties niet meer geldig zijn voor de sleutelprovider. De sleutelprovider kan de bijbehorende sleutel vervolgens verwijderen.
Een ander voorbeeld is wanneer een gebruiker naar de instellingenpagina van de RP gaat en de bestaande inloggegevens verwijdert. De RP kan dan Signal API gebruiken om een lijst met beschikbare inloggegevens door te geven aan de sleutelprovider, zodat de sleutelprovider de bijbehorende sleutels gesynchroniseerd kan houden.
Het kan ook een signaal geven over een gewijzigde gebruikersnaam en weergavenaam, zodat de wachtwoordmetadata die voor dezelfde gebruiker zijn opgeslagen, kunnen worden bijgewerkt.
Wanneer een gebruiker bijvoorbeeld zijn gebruikersnaam of weergavenaam op de RP bijwerkt, kan de RP Signal API gebruiken om de bijgewerkte gebruikersinformatie door te geven aan de sleutelprovider. Zo kan de sleutelprovider de gebruikersinformatie van de bijbehorende sleutels gesynchroniseerd houden.
Google Password Manager op Chrome desktop implementeert de Signal AP. Voor Chrome-extensiegebaseerde toegangssleutelproviders is het aan hen om te bepalen of ze het signaal al dan niet reflecteren.
We zijn van plan om Signal API in de toekomst op Android Chrome te ondersteunen.
Als u wilt weten hoe u de WebAuthn Signal API kunt integreren, leest u Houd de lijst met toegangssleutels gesynchroniseerd met de server met behulp van de Signal API .