Origin-proef: WebAuthn-directe bemiddeling voor probleemloos aanmelden

José Luis Zapata

Gepubliceerd: 19 aug. 2025

WebAuthn Direct Mediation is een nieuwe webfunctionaliteit die is ontworpen om de aanmeldprocessen van gebruikers te stroomlijnen . Deze proefversie biedt een overzicht van de functie, de voordelen en implementatiedetails, en nodigt u uit om deel te nemen en mee te helpen de toekomst van webauthenticatie vorm te geven.

Achtergrond

Authenticatie op het web leidt vaak tot problemen, waardoor het aanmelden van gebruikers ingewikkelder wordt. Bestaande WebAuthn-stromen zijn weliswaar krachtig, maar hebben moeite met aanmeldknoppen, vooral wanneer de inloggegevens niet direct beschikbaar zijn, wat leidt tot standaardformulieren.

Voorbeeld van een onmiddellijke bemiddelingsstroom

Deze nieuwe functie introduceert een soepele aanmeldprocedure , vergelijkbaar met preferImmediatelyAvailableCredentials API's op mobiele apparaten. Het vereenvoudigt het aanmelden, vaak vóór standaard inlogformulieren, door de soepelheid te verminderen en de gebruikerservaring te verbeteren.

Hoe het werkt

Directe bemiddeling van WebAuthn zorgt voor een directere en efficiëntere aanmeldervaring. Het stelt de browser in staat om direct beschikbare inloggegevens aan te bieden, of om direct de afwezigheid ervan te signaleren zonder te vragen om authenticatie via meerdere apparaten of een beveiligingssleutel. Dit vereenvoudigt de implementatie voor ontwikkelaars.

Het type immediate bemiddeling

We introduceren een immediate bemiddelingstype voor navigator.credentials.get() -aanvragen. Wanneer deze optie is ingesteld, wordt de belofte afgewezen met NotAllowedError als er geen lokaal beschikbare inloggegevens worden gevonden. Als er inloggegevens aanwezig zijn, verwerkt de browser het authenticatieproces zoals gebruikelijk.

Dankzij deze flexibiliteit kunnen sites hun aanmeldproces aanpassen en alternatieve methoden aanbieden wanneer de directe inloggegevens niet beschikbaar zijn.

Belangrijk is dat browsers nog steeds NotAllowedError kunnen retourneren om de privacy en veiligheid van gebruikers te waarborgen en problemen zoals vingerafdrukken of tracking te voorkomen.

Functiedetectie

U kunt controleren of directe bemiddeling beschikbaar is met PublicKeyCredential.getClientCapabilities() . Ontwikkelaars kunnen controleren op de mogelijkheid immediateGet in het geretourneerde capabilities -object.

async function checkImmediateMediationAvailability() {
  try {
    const capabilities = await PublicKeyCredential.getClientCapabilities();
    if (capabilities.immediateGet && window.PasswordCredential) {
      console.log("Immediate Mediation with passwords supported.");
    } else if (capabilities.immediateGet) {
      console.log("Immediate Mediation without passwords supported.");
    } else { console.log("Immediate Mediation unsupported."); }
  } catch (error) {
    console.error("Error getting client capabilities:", error);
  }
}

Let op: voor bredere browserondersteuning is er een polyfill voor getClientCapabilities() beschikbaar in de WebAuthn Polyfills GitHub-repository .

Voorbeeld implementatie

Om de API te gebruiken, roept u navigator.credentials.get() aan met mediation: 'immediate' . We raden aan om password: true in de aanvraag op te nemen, aangezien de meeste gebruikers waarschijnlijk al een wachtwoord hebben opgeslagen en hier direct profijt van kunnen hebben.

button.addEventListener('click', async (event) => {
  event.preventDefault();
  event.stopPropagation();
  const cred = await navigator.credentials.get({
    password: true,
    publicKey: {
      challenge, // Your server-generated challenge
      rpId: 'example.com' // Your Relying Party ID
    },
    mediation: 'immediate',
  });
});

Ontwikkelaars moeten de NotAllowedError verwerken in een catch -blok om een soepele fallback-aanmeldervaring te bieden.

Een stapsgewijze stroom voor onmiddellijke bemiddeling

Directe bemiddeling van WebAuthn ondersteunt twee primaire use cases om het aanmelden van gebruikers te stroomlijnen: het inschakelen van een speciale knop 'Aanmelden met wachtwoord' die ongewenste terugvalopties onderdrukt, en het faciliteren van een dynamische aanmeldstroom die proactief inloggegevens aanbiedt vóór een voor de gebruiker cruciale actie.

Gebruiksscenario 1: Expliciete aanmelding met aanmeldknop

In dit scenario ligt de nadruk op het aanbieden van een speciale aanmeldknop, waardoor een overzichtelijke gebruikerservaring ontstaat zonder onverwachte prompts of het doorlopen van een aanmeldpagina.

Stroom die laat zien dat Chrome al opgeslagen inloggegevens aanbiedt wanneer de gebruiker op de aanmeldknop klikt.
  1. Gebruiker initieert aanmelding: De gebruiker klikt op de knop 'Aanmelden'. De relying party roept vervolgens navigator.credentials.get() aan met mediation: "immediate" .
  2. Browser vraagt om inloggegevens (indien beschikbaar): De browser controleert op lokaal beschikbare toegangscodes of aangevraagde wachtwoorden. Als deze worden gevonden, verschijnt er direct een modale gebruikersinterface waarmee de gebruiker een account kan kiezen. Accounts worden gerangschikt op basis van het tijdstip van het laatst gebruikte wachtwoord en vervolgens alfabetisch. Opmerking : Als er zowel wachtwoorden als toegangscodes van meerdere wachtwoordbeheerders voor hetzelfde account worden gevonden, geeft de browser prioriteit aan de toegangscodes. Wanneer er meerdere toegangscodes van verschillende providers voor hetzelfde account bestaan, krijgt de laatst gebruikte toegangscode prioriteit.
  3. Succesvolle aanmelding: De gebruiker selecteert de toegangscode in de browserinterface. Als de browser verificatie vereist, wordt de gebruiker gevraagd zijn of haar identiteit te verifiëren met behulp van de eerder ingestelde methode (zoals een pincode, biometrische invoer of patroon). De aanmelding wordt succesvol voltooid.
  4. Terugvalpad: geen wachtwoord of gebruikersverwijdering: Als er geen lokale wachtwoorden of aangevraagde wachtwoorden beschikbaar zijn voor de site, of als de gebruiker de browserinterface verwijdert, genereert de browser een NotAllowedError voor de relying party en toont de browser geen gebruikersinterface voor opties voor meerdere apparaten of beveiligingssleutels. De relying party kan vervolgens doorgaan met de standaard aanmeldpagina of alternatieve authenticatiemechanismen aanbieden.

Gebruiksscenario 2: Impliciete aanmeldingsstroom vóór een gebruikersactie

Dit scenario maakt een proactieve aanmeldervaring mogelijk, waarbij toegangscodes en wachtwoorden worden aangeboden voordat een gebruiker een actie uitvoert waarvoor een geverifieerde status vereist is, zoals uitchecken.

Stroom waarin Chrome al opgeslagen inloggegevens aanbiedt wanneer de gebruiker een actie uitvoert waarvoor aanmelding vereist is.
  1. Gebruiker initieert actie waarvoor aanmelden vereist is: De gebruiker klikt op een knop voor een actie waarvoor aanmelden vereist is (bijvoorbeeld de knop 'Afrekenen'). De relying party roept vervolgens navigator.credentials.get() aan met mediation: "immediate" .

  2. Browser vraagt om inloggegevens (indien beschikbaar): De browser controleert op lokaal beschikbare toegangscodes of wachtwoorden. Als deze worden gevonden, verschijnt er direct een modale gebruikersinterface waarmee de gebruiker een account kan kiezen. Accounts worden gerangschikt op basis van de tijdstempel van het laatst gebruikte account, vervolgens alfabetisch en gededupliceerd, zodat er één item per account wordt weergegeven. Opmerking : Wanneer zowel wachtwoorden als toegangscodes van meerdere wachtwoordbeheerders voor hetzelfde account worden gevonden, geeft de browser prioriteit aan de toegangscodes. Wanneer er meerdere toegangscodes voor hetzelfde account van verschillende providers bestaan, krijgt de laatst gebruikte toegangscode prioriteit.

  3. Succesvolle aanmelding: De gebruiker selecteert een inloggegeven in de browserinterface. Als de browser verificatie vereist, wordt de gebruiker gevraagd zijn of haar identiteit te verifiëren met behulp van de eerder ingestelde methode (zoals een pincode, biometrische invoer of patroon). De aanmelding wordt succesvol voltooid.

  4. Terugvalpad: geen inloggegevens of gebruikersverwijdering: Als er geen lokale inloggegevens voor de site beschikbaar zijn of als de gebruiker de browserinterface verwijdert, genereert de browser een NotAllowedError voor de relying party en toont de browser geen gebruikersinterface. De aanmeldervaring van de gebruiker blijft ongewijzigd ten opzichte van vandaag. De relying party kan de gebruiker vervolgens om meer informatie vragen (bijvoorbeeld een e-mailadres) of alternatieve authenticatiemechanismen tonen, zoals een wachtwoordformulier, sms-verificatie of een modale WebAuthn-aanvraag die authenticators voor meerdere apparaten ondersteunt.

Voordelen

De directe bemiddeling van WebAuthn biedt verschillende belangrijke voordelen voor ontwikkelaars en gebruikers:

  • Aanmelden zonder gedoe: Dit zorgt voor een soepelere en eenvoudigere aanmeldervaring voor gebruikers die direct beschikbare wachtwoorden of toegangscodes hebben opgeslagen in hun browser of wachtwoordbeheerder.
  • Intelligente aanmelding: De API maakt een aanmeldproces mogelijk wanneer de gebruiker activiteiten wil uitvoeren waarvoor aanmelding vereist is. Deze processen passen zich intelligent aan de inloggegevens van de gebruiker aan. Het biedt onmiddellijke authenticatie waar mogelijk, waardoor onnodige omleidingen worden vermeden en de workflow wordt gestroomlijnd.
  • Verbeterd beheer van inloggegevens : wanneer meerdere wachtwoordbeheerders inloggegevens voor hetzelfde account aanbieden, selecteert de browser op intelligente wijze de meest geschikte optie, waardoor het beheer van inloggegevens voor gebruikers wordt vereenvoudigd.
  • Minder verwarring bij gebruikers: Door direct bekende inloggegevens te presenteren, minimaliseert de functie de verwarring bij gebruikers die vaak gepaard gaat met meerdere aanmeldopties of standaardformulieren.
  • Naadloze terugval: Hiermee wordt gezorgd voor een naadloze terugval naar standaard aanmeldpagina's voor gebruikers zonder directe inloggegevens. Dit betekent dat hun ervaring onveranderd blijft ten opzichte van de huidige stromen.

Privacy en veiligheid

Met WebAuthn-directe bemiddeling kunnen sites de aanwezigheid van direct beschikbare inloggegevens identificeren voordat een gebruiker expliciet een aanmeldpoging autoriseert. Om de privacy van gebruikers te beschermen en mogelijk misbruik te voorkomen, implementeren we verschillende belangrijke maatregelen:

  • Vereiste gebruikersgebaar: De API-aanroep vereist een gebruikersgebaar (elke tijdelijke gebruikersactivering). Dit maakt stille controle en vingerafdrukken lastig voor sites.
  • Incognito- en privésessies: in incognito- of privésessies genereert elk direct bemiddelingsverzoek de NotAllowedError .
  • Beperkingen op allowCredentials -lijsten: Verzoeken die gebruikmaken van allowCredentials -lijsten genereren NotAllowedError . Dit voorkomt dat sites de interactiegeschiedenis van gebruikers afleiden of gebruikers over sessies heen volgen.
  • Annulering: Het instellen van de signal op een verzoek met onmiddellijke bemiddeling is ongeldig. Dit voorkomt dat sites programmatisch een browserinterface negeren.

Probeer het eens

Wij raden u aan om te experimenteren met WebAuthn-directe bemiddeling.

Status in Chrome

Deze functie wordt momenteel ontwikkeld in de Chromium-ontwikkelingscyclus:

  • Desktop: Dev Trial in Chrome 136, met een Origin Trial van Chrome 139 tot 141.
  • Android: Dev-proefversie in Chrome 140.

Voor lokale tests

Om WebAuthn-directe bemiddeling lokaal te testen:

  1. Download Chrome 139: Download en open de nieuwste versie van Chrome op uw bureaublad.
  2. Schakel de vlag 'Onmiddellijke bemiddeling' in: Ga naar chrome://flags/#web-authentication-immediate-get in de adresbalk en schakel de vlag 'Web Authentication Immediate Get' in.
  3. Inloggegevens voorbereiden: Zorg dat u bruikbare toegangscodes en wachtwoorden hebt opgeslagen:
    • Wachtwoorden opgeslagen in Google Password Manager.
    • Toegangscodes die zijn opgeslagen in Google Password Manager (vereist aanmelden bij en synchroniseren van Chrome met een Google-account), Windows Hello of iCloud-sleutelhanger.

Voor openbare tests (oorspronkelijke proef)

Om WebAuthn-directe bemiddeling met de oorspronkelijke proef in een openbare omgeving te testen:

  1. Aanmelden: Ga naar de Chrome Origin Trials-pagina en meld u aan voor de proefperiode 'WebAuthn immediate mediation' .
  2. Token toevoegen aan HTTP-headers: Voeg het opgegeven origin trial-token toe aan de HTTP-headers van uw site: HTML Origin-Trial: [YOUR_TRIAL_TOKEN]

Let op: U kunt uw tokens ook programmatisch met JavaScript aanleveren .

Testscenario's

Wij bieden een referentie-implementatie en moedigen u aan om uw eigen prototype te bouwen om verschillende scenario's te testen.

  • Referentiedemo: U kunt de referentie-implementatie proberen op https://deephand.github.io/webauthn-immediate-demo/ .
    • Implementeer een prototype: Wanneer u een prototype op uw site implementeert, zorg er dan voor dat u de navigator.credentials.get() -aanroep uitvoert met mediation: 'immediate' nadat een gebruiker heeft geklikt (bijvoorbeeld op een knop 'Aanmelden' of een andere interactie waarvoor de gebruiker moet zijn aangemeld).
  • Stap 1: Aanmelden zonder wachtwoord of sleutel: Als u geen sleutels of wachtwoorden voor de site hebt, wordt u door op 'Aanmelden' te klikken direct naar de standaard aanmeldpagina geleid, zonder dat er een browserinterface wordt weergegeven.
  • Stap 2: Meld u aan met een direct beschikbare lokale toegangssleutel: Als u een toegangssleutel voor de site hebt opgeslagen, zou u door op 'Aanmelden' te klikken de gebruikersinterface voor directe bemiddeling moeten openen, waarin u de toegangssleutel kunt selecteren.
  • Stap 3: Aanmelden met een lokale toegangssleutel of wachtwoord: Als u zowel toegangssleutels als wachtwoorden hebt opgeslagen, schakelt u de optie 'Wachtwoord opvragen' in (door password: true in uw code in te stellen). Door op 'Aanmelden' te klikken, worden zowel de toegangssleutel als het wachtwoord weergegeven in de gebruikersinterface voor directe bemiddeling.