Gepubliceerd: 13 november 2024
Vanaf Chrome 132 ondersteunt Chrome desktop (macOS, Windows, Linux en ChromeOS) de Signal API die ervoor kan zorgen dat de toegangscodes op toegangscodeproviders consistent blijven met de inloggegevens voor de openbare sleutel op de server van de vertrouwende partij.
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 toegangscode (zoals een wachtwoordbeheerder), en wordt de inloggegevens van de openbare sleutel 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 wachtwoordsleutel hij zich moet aanmelden, omdat de gebruiker wordt gevraagd een wachtwoordsleutel te selecteren bij het inloggen. Dit is vooral handig als hij meer dan twee wachtwoordsleutels van verschillende wachtwoordsleutelproviders heeft.
Er zijn echter een aantal gevallen waarin verschillen tussen de lijst met wachtwoordsleutels op de sleutelprovider en de lijst met inloggegevens op de server voor verwarring kunnen zorgen.
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 de toegangssleutel, wordt de 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 verwijderde openbare sleutel.
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, ook al zijn deze op de server bijgewerkt. Idealiter zouden ze synchroon moeten zijn.
Signaal-API
Met de WebAuthn Signal API kunnen RP's bestaande inloggegevens doorgeven aan aangesloten wachtwoordproviders. Hierdoor kan een ondersteunende wachtwoordsleutelprovider onjuiste of ingetrokken wachtwoordsleutels uit zijn opslag bijwerken of verwijderen, zodat deze consistent is met de server.
Wanneer een gebruiker zich bijvoorbeeld niet aanmeldt bij een RP omdat de bijbehorende inloggegevens op de RP-server niet meer bestaan, kan de RP de Signal API gebruiken om aan te geven dat de verwijderde inloggegevens niet langer geldig zijn voor de toegangscodeprovider, zodat de toegangscodeprovider kunt u de bijbehorende toegangscode verwijderen.
Een ander voorbeeld is dat wanneer een gebruiker naar de instellingenpagina van de RP gaat en de bestaande inloggegevens verwijdert, de RP de Signal API kan gebruiken om een lijst met beschikbare inloggegevens door te geven aan de aanbieder van de toegangssleutel, zodat de aanbieder van de toegangscode de bijbehorende toegangscodes gesynchroniseerd kan houden.
Het kan ook een bijgewerkte gebruikersnaam en weergavenaam signaleren, zodat de metagegevens van de wachtwoordsleutel 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 wachtwoordsleutelprovider, zodat de wachtwoordsleutelprovider de gebruikersinformatie van de bijbehorende wachtwoordsleutels gesynchroniseerd kan houden.
Google Wachtwoordmanager op Chrome-desktop implementeert het Signal AP. Voor aanbieders van op Chrome-extensies gebaseerde wachtwoordsleutels is het aan hen of ze het signaal wel of niet weerspiegelen.
We zijn van plan om in de toekomst de Signal API op Android Chrome te ondersteunen.
Voor meer informatie over het integreren van de WebAuthn Signal API leest u De lijst met wachtwoordsleutels gesynchroniseerd houden met de server met behulp van de Signal API .