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, dienen het formulier in en de site verifieert de ondertekende e-mailverificatietoken van de browser bij de provider zonder een e-mail te sturen of de gebruikersflow te onderbreken.

Als sites een e-mailadres verzamelen tijdens de aanmelding, inlog, betaling, nieuwsbriefabonnement of account recovery, bevestigen ze meestal dat de persoon die het formulier indient, het adres beheert. 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 sessiebeëindigingen voor zowel menselijke gebruikers als geautomatiseerde agents. Gebruikers ervaren vaak problemen met bestaande verificatiemethoden, zoals vertraagde e-mails, verlopen links of niet-herkende codes.

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

E-mailverificatie is een progressieve verbetering van je bestaande proces:

  • Geen onderbreking: Verificatie vindt op de achtergrond plaats terwijl de gebruiker het formulier invult.
  • Geen functieherkenning 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.
  • Minimaliseer het risico op phishing: Er is geen code om te kopiëren en er is geen mogelijkheid om de gebruiker naar een nep-site te sturen.

Je kunt de flow testen in de demo:

Overwegingen voor origin trials

Origin trials zijn experimenten om feedback te verzamelen. Je inbreng is dus essentieel als je deelneemt als afhankelijke partij of identiteitsprovider. Gebruik de volgende GitHub-opslagplaatsen om problemen te melden:

Als je bugs tegenkomt in de Chrome-implementatie, dien je een probleem in voor 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 vóór de lancering op de functie vertrouwen. 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 als u de Email Verification API gebruikt.

Belangrijke termen

Dit zijn de belangrijkste termen voor de Email Verification API:

  • Verificator: De site die het e-mailadres verzamelt en het wil laten verifiëren. De verificateur wordt ook wel de Relying Party 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 kaartuitgever 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 gebruikt met de identiteitsprovider 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.

Protocolstroom

Architectuur van het e-mailverificatieproces
Architectuur van het proces voor e-mailverificatie
  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. Discovery en sessie: De browser vraagt het DNS TXT-record voor _email-verification.<email-domain> op om de geautoriseerde oorsprong van de uitgever te vinden en checkt daarna of de gebruiker een actieve sessie heeft met de .well-known/web-identity-configuratie en FedCM-account-eindpunten van de uitgever. Als het domein geen EVP-record publiceert of er geen actieve sessie bestaat, stopt de browser de verificatie zonder de gebruiker om een prompt te vragen.
  4. Tokenuitgifte: De browser ontdekt de issuance_endpoint van de provider via .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 ondertekende e-mailverificatietoken (EVT) te krijgen.
  5. Sleutelbinding en indienen: De browser bindt de ondertekende EVT aan de oorsprong van de vertrouwende partij en het formulier nonce in een JWT voor sleutelbinding (KB-JWT). Als de gebruiker het formulier indient, vult Chrome de verborgen invoer in met de gecombineerde token (<EVT>~<KB-JWT>) en toont Chrome een kleine melding waarin de gebruiker wordt geïnformeerd dat hun e-mailprovider hun adres heeft geverifieerd.
  6. Claims en KB valideren: De server van de afhankelijke partij 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 tijdelijke 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 EVThandtekening van de uitgeverJWKS met de openbare sleutel van de provider. 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 laat verifiëren, toont Chrome een toestemmingsprompt (een dialoogvenster op desktop of een blad onderaan op Android) voordat een token wordt aangevraagd. Als dit recht is toegekend, wordt het per e-mailadres onthouden op deelnemende sites.

Chrome-instellingen

Gebruikers kunnen hun geverifieerde e-mails 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 de indiening of als een van de validatiestappen mislukt, kun je terugvallen op het standaard e-mailbevestigingsproces. Dit betekent ook dat er geen functieherkenning voor de API is. 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.