E-mailverificatie

De Email Verification API is een voorstel waarmee de browser rechtstreeks met de e-mailprovider kan communiceren om te verifiëren dat de gebruiker de eigenaar van het e-mailadres is. Gebruikers voeren hun e-mailadres in en dienen het formulier in. De site verifieert de ondertekende e-mailverificatietoken van de browser bij de provider zonder een e-mail te sturen of de gebruikersstroom te onderbreken.

Als sites een e-mailadres verzamelen tijdens aanmelding, inloggen, afrekenen, abonneren op een nieuwsbrief of accountherstel, bevestigen ze meestal dat de persoon die het formulier indient, de eigenaar van het adres is. Voor bestaande verificatiemethoden moeten gebruikers uw site verlaten, van app wisselen om hun inbox te checken, een OTP kopiëren of op een verificatielink klikken. Deze onderbreking leidt tot meer uitval en verlaten sessies voor zowel menselijke gebruikers als geautomatiseerde agents. Gebruikers ondervinden vaak problemen met bestaande verificatiemethoden, zoals vertraagde e-mails, verlopen links of niet-herkende codes.

Demo van gebruikersprompt voor e-mailverificatie
Demo van gebruikersprompt voor e-mailverificatie

E-mailverificatie fungeert als een progressive enhancement voor je bestaande proces:

  • Geen onderbreking: Verificatie vindt op de achtergrond plaats terwijl de gebruiker het formulier invult.
  • Geen functiedetectie vereist: Sites voegen een e-mailinvoer en een verborgen tokeninvoer toe aan hun formulieren. Als de browser of provider geen e-mailverificatie ondersteunt of als de verificatie mislukt, valt de site terug op het standaard e-mailbevestigingsproces.
  • Het risico op phishing minimaliseren: Er is geen code om te kopiëren en er is geen mogelijkheid om de gebruiker naar een nepsite te sturen.

Je kunt het proces testen in de demo:

Overwegingen voor origin trials

Origin trials zijn experimenten om feedback te verzamelen. Je input is dus essentieel als je deelneemt als een Relying Party of een identiteitsprovider. Gebruik de volgende GitHub-opslagplaatsen om problemen te melden:

Als je bugs tegenkomt in de Chrome-implementatie, meld je een probleem in de volgende component:

Je beheert de functionaliteit van de origin trial per reactie door de origin trialtoken op te nemen. Zo kun je de functie beperken tot een specifiek segment van je gebruikers, zoals een A/B-testpopulatie. Als je een groep gebruikers hebt voor bètatests of vroege previews, wil of moet je de functie misschien aanzetten voor hen. Check in dit geval het verstrekte e-mailadres voordat je de token uitgeeft of valideert.

Origin trials hebben ook verkeerslimieten om te voorkomen dat sites de functie gebruiken voordat deze wordt gelanceerd. De uitgever-API is in ontwikkeling. Je kunt dus wijzigingen verwachten die niet achterwaarts compatibel zijn, samen met updates van de Chrome-UX.

Houd de blog en de mailinglijst evp-announce@chromium.org in de gaten voor verdere updates naarmate de ontwikkeling vordert.

Proces voor e-mailverificatie

In de volgende gedeelten worden de belangrijkste termen en protocolstappen uitgelegd bij het gebruik van de API voor e-mailverificatie.

Belangrijke termen

Dit zijn de belangrijkste termen voor de e-mailverificatie API:

  • Verificatie-instantie: De site die het e-mailadres verzamelt en wil verifiëren. De verificateur wordt ook wel de vertrouwende partij genoemd.
  • E-mailprovider: De service die het e-mailadres van de gebruiker levert, bijvoorbeeld gmail.com.
  • Uitgever: De service die het account voor het e-mailadres van de gebruiker beheert, bijvoorbeeld accounts.google.com. De uitgever wordt ook wel de identiteitsprovider genoemd.

In sommige gevallen werken de e-mailprovider en de uitgever vanuit hetzelfde domein. Het is wel belangrijk om onderscheid te maken tussen deze 2, omdat de Email Verification API de actieve sessie in de browser met de identiteitsprovider gebruikt als verificatiemethode. Als je bijvoorbeeld wilt verifiëren example@gmail.com, moet de gebruiker met dat account zijn ingelogd op google.com in dezelfde browser.

Protocolproces

Architectuur van het e-mailverificatieproces
Architectuur van het e-mailverificatieproces
  1. Formulierpresentatie: De vertrouwende partij levert een HTML-formulier met een <input type="email"> en een verborgen invoer gemarkeerd met autocomplete="email-verification-token" en een unieke nonce per instantie.
  2. E-mailinvoer: Als de gebruiker een e-mailadres invoert (door een suggestie voor automatisch invullen te selecteren of door te typen of te plakken en het veld te verlaten (blur)), activeert de browser de verificatie op de achtergrond.
  3. Detectie en sessie: De browser voert een query uit op de DNS TXT-record voor _email-verification.<email-domain> om de geautoriseerde oorsprong van de uitgever van de provider te ontdekken. Daarna controleert de browser of de gebruiker een actieve sessie heeft via de .well-known/web-identity-configuratie van de uitgever en de FedCM-accounteindpunten. Als het domein geen EVP-record publiceert of als er geen actieve sessie bestaat, stopt de browser de verificatie zonder de gebruiker om toestemming te vragen.
  4. Tokenuitgifte: De browser ontdekt de issuance_endpoint van de provider van .well-known/email-verification, maakt een tijdelijk sleutelpaar en stuurt een HTTP POST-verzoek met HTTP-berichtenhandtekeningen (RFC 9421) met de first-party sessiecookies van de uitgever en het doel-e-mailadres om een ondertekend e-mailverificatietoken (EVT) te krijgen.
  5. Sleutelbinding en indienen: De browser bindt de ondertekende EVT aan de oorsprong van de Relying Party en het formulier nonce in een JWT voor sleutelbinding (KB-JWT) en toont een kleine melding om de gebruiker te laten weten dat de e-mailprovider het adres heeft geverifieerd. Als de gebruiker het formulier indient, vult Chrome de verborgen invoer in met de gecombineerde token (<EVT>~<KB-JWT>).
  6. Claims en KB valideren: De server van de Relying Party parseert de <EVT>~<KB-JWT>-token, valideert de verwachte claims (email, email_verified, aud, nonce, iat en exp) en verifieert de handtekening van de sleutelbinding aan de hand van de kortstondige openbare sleutel in cnf.jwk.
  7. DNS en openbare sleutels: De vertrouwende partij vraagt de _email-verification.<email-domain> DNS TXT-record op om te bevestigen dat deze overeenkomt met de iss-claim van de token. Daarna haalt de vertrouwende partij de .well-known/email-verification-metadata en openbare sleutels van de uitgever op uit jwks_uri.
  8. EVT verifiëren en afronden: De vertrouwende partij verifieert de handtekening van de uitgever EVT met de openbare sleutel van de provider JWKS. Als er geen token wordt ontvangen of als een validatiestap mislukt, valt de site terug op het bestaande e-mailbevestigingsproces.

De eerste keer dat een gebruiker een e-mailadres verifieert, toont Chrome een toestemmingsprompt (een dialoogvenster op een desktop of een blad onderaan op Android) voordat er een token wordt aangevraagd. Als je dit recht verleent, wordt het per e-mailadres onthouden op deelnemende sites.

Chrome-instellingen

Gebruikers kunnen hun geverifieerde e-mailadressen beheren:

  • Op een desktop onder Instellingen > Automatisch invullen en wachtwoorden > Contactgegevens > Geverifieerd e-mailadres (of open chrome://settings/contactInfo)
  • Op Android onder Instellingen > Adressen en meer > Geverifieerd e-mailadres

Gebruikers kunnen de functie helemaal uitzetten of afzonderlijke geverifieerde e-mailadressen beheren.

Overwegingen voor use cases

E-mailverificatie is een progressieve verbetering van uw bestaande proces. Hierdoor hoeft een gebruiker uw site niet te verlaten om een eenmalig wachtwoord op te halen of op een link te klikken. Sites kunnen de velden voor e-mailverificatie toevoegen aan alle relevante formulieren, zoals inlogformulieren, aanmeldingen voor nieuwsbrieven, accountcreatie en wachtwoordherstel. EVP wordt alleen geactiveerd als de browser dit ondersteunt. Als er geen code wordt ontvangen bij het indienen of als een van de validatiestappen mislukt, kun je terugvallen op je standaardproces voor e-mailbevestiging. Dit betekent ook dat er geen functiedetectie is voor de API. De verifiersite behandelt de EVT als optioneel en verwerkt deze als deze aanwezig is in het verzoek.

E-mailverificatie bevestigt dat de gebruiker een actieve sessie heeft bij de provider van het e-mailadres. Het verifieert niet of je e-mail de gebruiker heeft bereikt. Je wilt misschien nog steeds bestaande welkomst- of introductiemails sturen en de gebruiker vragen de spaminstellingen te checken.