Test het e-mailverificatieprotocol met een test van de oorspronkelijke bron.

Rowan Merewood

Gepubliceerd: 8 juli 2026

Bij het verzamelen van een e-mailadres als onderdeel van een registratie-, inlog-, abonnements-, afreken-, accountherstel- of ander proces, is het gebruikelijk om te controleren of het e-mailadres daadwerkelijk van de persoon is die het invoert. Bestaande verificatiemethoden, zoals eenmalige wachtwoorden (OTP's) of e-mailverificatielinks (magische links), vereisen dat de gebruiker uw website verlaat. Dit storende proces kan het risico vergroten dat de gebruiker, of het nu een mens of een medewerker is, zijn sessie volledig afbreekt en het authenticatieproces nooit voltooit.

De Email Verification API is een voorstel waarmee de browser rechtstreeks met de e-mailprovider kan communiceren om te verifiëren of de gebruiker daadwerkelijk de eigenaar is van het e-mailadres. Gebruikers selecteren een e-mailadres uit de suggesties voor automatisch invullen of aanvullen van de browser, verzenden het formulier en de website verifieert het e-mailadres bij de provider zonder een e-mail te versturen of de gebruikerservaring te onderbreken.

Het verzamelen van e-mailadressen is een cruciaal conversiepunt in het klanttraject, en Chrome wil graag feedback ontvangen over dit voorstel van websites die e-mailadressen willen verifiëren, e-mailproviders die de verificatie kunnen uitvoeren en gebruikers die het proces al ervaren. U kunt zich vandaag nog aanmelden voor de Origin-proefversie en de implementatie-instructies hier volgen. Raadpleeg Aan de slag met Origin-proefversies voor algemene configuratie-informatie over de Origin-proefversie .

Je kunt de workflow uitproberen met een demo-account:

• De Issuer-demo biedt u een gesimuleerd e-mailaccount en een gesimuleerde sessie.
• De Verifier-demo zal elke deelnemende aanbieder verifiëren.

E-mailverificatieproces

In de volgende paragrafen wordt uitgelegd wat u en uw gebruikers nodig hebben om het e-mailverificatieproces te starten, en hoe de volledige workflow verloopt bij gebruik van het e-mailverificatieprotocol.

Kernbegrippen

De belangrijkste termen voor de e-mailverificatie-API zijn als volgt:

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

In sommige gevallen opereren de e-mailprovider en de uitgever vanuit hetzelfde domein. Het is echter belangrijk om onderscheid te maken tussen het hebben van een e-mailadres en het hebben van een actieve sessie voor het bijbehorende account.

Voorwaarden

• De gebruiker moet ingelogd zijn bij zijn of haar e-mailprovider of -uitgever op hetzelfde browserprofiel. Als de gebruiker bijvoorbeeld Gmail gebruikt, moet hij of zij ingelogd zijn op het Google-account.
• Als deelnemende verificatiesite moet u zich aanmelden voor de Origin-proef en het token op dezelfde pagina als uw e-mailformulier invullen.

• De gebruiker moet zijn of haar e-mailadres selecteren uit het keuzemenu voor automatisch invullen of aanvullen.

  • Als de gebruiker eerder een e-mailadres in het veld heeft ingevoerd, wordt dit automatisch aangevuld.

  • Als de gebruiker zijn e-mailadres heeft toegevoegd via de Chrome-instellingen "Automatisch invullen en wachtwoord" ( chrome://settings/autofill ), wordt dit automatisch ingevuld.

• De eerste keer dat een gebruiker een e-mailadres ter verificatie opgeeft, verschijnt er een toestemmingsprompt. Dit gebeurt slechts één keer per e-mailadres.

Zodra de gebruiker een actieve sessie in zijn browser heeft, kan hij het proces starten:

1. Op een formulier met een e-mailveld selecteert de gebruiker zijn of haar e-mailadres uit de autocomplete-dropdown. De verificatiesite biedt een verborgen veld in het formulier met een unieke nonce om dit verzoek te valideren.

2. De browser haalt vervolgens het DNS-record voor e-mailverificatie op voor het betreffende e-maildomein. Dit verwijst de browser naar de uitgever. De uitgever bevestigt vervolgens dat er een actieve sessie is voor dat e-mailadres.

3. De uitgever verstrekt vervolgens zijn e-mailverificatietoken (EVT) voor het adres. De browser combineert dit met het EVT, de site-oorsprong en de nonce uit het invoerformulier tot een sleutelgebonden JWT.

4. Wanneer het formulier wordt verzonden, wordt het EVT-pakket toegevoegd aan het verborgen veld en naar de site gestuurd.

5. De verificatiesite controleert vervolgens elk van deze gegevens: het verwachte e-mailadres, de nonce en de handtekeningen van de browser en de uitgever.

6. De gebruiker ziet een kleine melding dat zijn e-mailprovider zijn adres heeft geverifieerd.

Dit proces geeft de verificatiesite bevestiging dat het e-mailadres geldig is en toebehoort aan de huidige gebruiker, waardoor de site het versturen van een verificatiemail kan overslaan.

Gebruikers kunnen hun geverifieerde e-mailadressen beheren via Instellingen > Automatisch invullen en wachtwoorden > Contactgegevens > Geverifieerd e-mailadres (of open chrome://settings/contactInfo ).

Overwegingen met betrekking tot gebruiksscenario's

E-mailverificatie is een progressieve verbetering van uw bestaande workflow, waardoor gebruikers uw site niet meer hoeven te verlaten om een ​​OTP (eenmalige wachtcode) op te halen of op een link te klikken. Websites kunnen de velden voor e-mailverificatie toevoegen aan alle relevante formulieren, zoals inlogformulieren, nieuwsbriefaanmeldingen, accountaanmaak en wachtwoordherstel. EVP (Email Verification Process) wordt alleen geactiveerd als de browser dit ondersteunt. Als er geen code wordt ontvangen bij het verzenden van het formulier of als een van de validatiestappen mislukt, kunt u terugvallen op uw standaard e-mailbevestigingsworkflow. Dit betekent ook dat er geen functiedetectie voor de API plaatsvindt; de verificatiesite beschouwt de EVT als optioneel en verwerkt deze alleen als deze in het verzoek aanwezig is.

E-mailverificatie bevestigt dat de gebruiker een actieve sessie heeft met de provider van zijn of haar e-mailadres. Het verifieert niet of uw e-mail de gebruiker daadwerkelijk heeft bereikt. U wilt wellicht nog steeds bestaande welkomst- of onboarding-e-mails versturen en de gebruiker mogelijk vragen om zijn of haar spaminstellingen te controleren.

Implementeer de verificatiesite

Voor meer details kunt u de volledige democode bekijken en de validatiestappen raadplegen in de voorstellen voor de Email Verification API en het Email Verification Protocol .

Formuliervelden configureren

Zorg ervoor dat uw formuliervelden de juiste kenmerken hebben:

<input
  name="email-address"
  type="email"
  autocomplete="email">
<input
  type="hidden"
  name="token"
  nonce="rAnD0m-VaLuE"
  autocomplete="email-verification-token">

Stel de type en autocomplete attributen van het email mailinvoerveld in op email zodat de browser een autocomplete-optie voor het e-mailadres kan aanbieden.

Het nieuwe hidden veld wordt bij het verzenden van het formulier gevuld met het e-mailverificatietoken. De benodigde attributen zijn:

• Stel type="hidden" omdat voor dit veld geen gebruikersinvoer vereist is.
• Stel nonce="rAnD0m-VaLuE" . De site moet een unieke, aan de sessie gebonden nonce verstrekken om de formulierinzending te verifiëren.
• Stel autocomplete="email-verification-token" in. De browser gebruikt dit attribuut om het veld te identificeren dat moet worden ingevuld.

Valideer uw formulierelementen door het netwerkpaneel in de ontwikkelaarstools te controleren. Wanneer u een e-mailadres selecteert, ziet u dat de browser de DNS- en daaropvolgende accountopzoekquery's uitvoert voor de e-mailprovider en -uitgever. Dit zijn interne browserverzoeken; uw site ontvangt pas informatie nadat het formulier is verzonden.

Valideer de EVT

Er zijn vijf stappen om elk onderdeel van het EVT-pakket te valideren.

1. Analyseer het token.
2. Valideer de verwachte waarden.
3. Valideer de toetsencombinatie.
4. Valideer het DNS-record.
5. Ontdek de uitgever en verifieer de EVT-handtekening.

1. Analyseer het token

De ruwe data van de formulierinzending bevat de EVT en ondertekende claims in een Selective Disclosure JSON Web Token (SD-JWT+KB), gescheiden door een tilde ( ~ ). U moet deze scheiden en de Javascript Object Signing and Encryption (JOSE) headers en payloads decoderen (bijvoorbeeld met behulp van jose voor Node.js).

Als example.com demo@gmail.com verifieert, ziet de gedecodeerde payload er ongeveer zo uit als in het volgende voorbeeld:

{
  "evtJwtDecodedPayload": {
    "cnf": {
      "jwk": {
        "crv": "Ed25519",
        "kty": "OKP",
        "x": "pUbLiCkEy123pUbLiCkEy123pUbLiCkEy123"
      }
    },
    "email": "demo@gmail.com",
    "email_verified": true,
    "iat": 1782911685,
    "iss": "https://accounts.google.com"
  },
  "kbJwtDecodedPayload": {
    "aud": "https://example.com",
    "iat": 1782911685,
    "nonce": "rAnDoM123rAnDoM123rAnDoM123rAnDoM123",
    "sd_hash": "hAsH456hAsH456hAsH456hAsH456hAsH456"
  }
}

2. Valideer de verwachte waarden

Controleer of de basiswaarden in de payload overeenkomen met de door u opgegeven waarden:

• Controleer of email_verified is ingesteld op true .
• Controleer of het email overeenkomt met het e-mailadres dat u in het formulier hebt opgegeven.
• Controleer of de nonce overeenkomt met de nonce die u in uw formulier hebt opgegeven.
• Controleer of aud overeenkomt met de herkomst van uw site.
• Controleer of iat een relatief recente tijdstempel heeft, bijvoorbeeld na het moment waarop het formulier werd weergegeven.

3. Valideer de toetsencombinatie

De browser genereert een tijdelijke, vluchtige sleutel voor de transactie om te bevestigen dat het token is ondertekend. Haal deze sleutel uit de cnf -claim (confirmation) in de EVT en gebruik deze vervolgens om de aan de sleutel gekoppelde JWT te verifiëren.

Bereken vervolgens de verwachte hash en vergelijk deze met de claim sd_hash . Het volgende Node.js-voorbeeld laat zien hoe u deze berekening uitvoert:

const calculatedHash = createHash("sha256")
        .update(evtJwt + "~")
        .digest("base64url");

4. Valideer het DNS-record

Controleer het DNS-record _email-verification voor het domein van het e-mailadres. Bijvoorbeeld, voor demo@gmail.com , vraag het TXT record _email-verification.gmail.com op. Voor deze provider retourneert de query de locatie van de accountprovider, namelijk accounts.google.com .

$ dig +short TXT _email-verification.gmail.com
"iss=accounts.google.com"

5. Achterhaal de uitgever en verifieer de EVT-handtekening.

Zorg ervoor dat de uitgever de resource /.well-known/email-verification beschikbaar stelt, die de eindpunten voor het uitgeven van het token, de JSON Web Key (JWK) voor de site en de ondersteunde ondertekeningsalgoritmen bevat.

$ curl https://accounts.google.com/.well-known/email-verification
{
  "issuance_endpoint": "https://accounts.google.com/gsi/email-verification/issue",
  "jwks_uri": "https://verifiablecredentials-pa.googleapis.com/.well-known/vc-public-jwks",
  "signing_alg_values_supported": ["EdDSA"]
}

Gebruik de JWK's om de EVT JWT te verifiëren die je uit het token hebt gehaald. De meeste JOSE-bibliotheken bieden functies om deze verificatie af te handelen.

Als alle vijf stappen succesvol zijn, is het e-mailadres geverifieerd bij de provider. Zo niet, stuur dan een bevestigingsmail naar de gebruiker volgens de normale procedure.

Implementeer de e-mailprovider- en -uitgeverservice.

Voor meer details kunt u de democode van de gesimuleerde e-mailprovider bekijken en de stappen voor de uitgever raadplegen in de voorstellen voor de Email Verification API en het Email Verification Protocol .

Als uitgever hoeft u zich niet aan te melden voor de origin trial of een token te verstrekken, aangezien het browsergedrag wordt geactiveerd door de website van de relying party. U hoeft er alleen voor te zorgen dat de verwachte eindpunten aanwezig zijn om op die verzoeken te reageren.

Configureer de detectie van uitgevers

Om ervoor te zorgen dat browsers uw verificatie-eindpunten automatisch kunnen vinden wanneer een e-mailadres van uw domein wordt geselecteerd, kunt u uw configuratie beschikbaar maken via DNS en een .well-known HTTP-eindpunt.

Configureer het DNS-delegatierecord.

Configureer een DNS TXT -record op uw e-maildomein dat de verificatiebevoegdheid delegeert aan uw uitgever-ID. Deze ID's kunnen, afhankelijk van uw infrastructuur, hetzelfde domein gebruiken.

Recordindeling: _email-verification.<email-domain>

Voorbeeld zonebestand:

_email-verification.example.com IN TXT "iss=accounts.issuer.example"

Host een .well-known/email-verification eindpunt

Plaats een JSON-metadatabestand op uw uitgeverdomein onder het pad /.well-known/ . Dit bestand beschrijft uw uitgiftemogelijkheden en de cryptografische ondertekeningsalgoritmen die uw infrastructuur ondersteunt.

Eindpunt: https://<issuer-domain>/.well-known/email-verification

Voorbeeldantwoord:

{
  "issuance_endpoint": "https://accounts.issuer.example/email-verification/issuance",
  "jwks_uri": "https://accounts.issuer.example/.well-known/vc-public-jwks",
  "signing_alg_values_supported": ["EdDSA", "ES256"]
}

Host een .well-known/web-identity -eindpunt

Een extra .well-known JSON-resource die u mogelijk al hebt geïmplementeerd als onderdeel van de Federated Credentials (FedCM) API . Deze biedt links naar het eindpunt van uw account en de inlog-URL.

Eindpunt: https://<domain>/.well-known/web-identity

Voorbeeldantwoord:

{
  "accounts_endpoint": "https://accounts.issuer.example/accounts",
  "login_url": "https://accounts.issuer.example/login"
}

Gebruik een account-eindpunt

Het accounts-eindpunt van de FedCM API geeft een lijst weer van de accounts die momenteel zijn aangemeld. Het volgende voorbeeld toont een minimale respons. Raadpleeg de implementatiehandleiding voor identiteitsproviders voor meer informatie.

Eindpunt: zoals gespecificeerd in .well-known/web-identity

Hieronder volgt een voorbeeldantwoord:

{
  "accounts": [
    {
      "id": "demo-example",
      "name": "Demo User",
      "email": "demo@example.com",
      "given_name": "Demo"
    }
  ]
}

Integreer met de Login Status API

De gebruiker moet een actieve sessie met de provider hebben en u moet dit aan de browser signaleren met de Login Status API .

Wanneer een gebruiker succesvol in- of uitlogt, moet de bijbehorende HTTP-antwoordheader worden verzonden:

Set-Login: logged-in
Set-Login: logged-out

U kunt de status ook bijwerken met behulp van JavaScript in de context van uw webapplicatie:

navigator.login.setStatus("logged-in");
navigator.login.setStatus("logged-out");

Verwerk uitgifteverzoeken

Uw issuance_endpoint ontvangt een application/x-www-form-urlencoded POST verzoek dat de request_token bevat.

De volgende paragrafen tonen het volledige proces van het afhandelen van uitgifteverzoeken.

1. Valideer het uitgifteverzoek

Inkomende browsergegevens analyseren en valideren:

• Methode: POST
• Sessieverificatie: Valideer de first-party session/authentication van de gebruiker die met het verzoek worden meegestuurd om te garanderen dat er een actieve, geautoriseerde identiteitscontext bestaat.
• Parameterverificatie: Haal de parameter request_token (een ondertekend JWT gegenereerd door de browser) eruit. Controleer of deze de verwachte tijdelijke publieke sleutel, het doel-e-mailadres, de juiste doelgroep en een geldige tijdstempel bevat.

Het gedecodeerde token zou er ongeveer zo uit moeten zien:

{
  "decodedHeader": {
    "alg": "ES256",
    "typ": "JWT",
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "pUbLiCKeY123pUbLiCKeY123pUbLiCKeY123",
      "y": "pUbLiCKeY456pUbLiCKeY456pUbLiCKeY456"
    }
  },
  "decodedPayload": {
    "iss": "https://accounts.issuer.example",
    "sub": "demo@example.com",
    "email": "demo@example.com",
    "iat": 1780272000,
    "exp": 1780272300
  },
  "signature": "SIGnatURE-123_SIGnatURE-123_SIGnatURE-123"
}

2. Reageer met een token

Na succesvolle validatie van de sessie en het aanvraagtoken, genereer een ondertekende Selective Disclosure JWT (SD-JWT) met behulp van de payload:

{
  "iss": "https://accounts.issuer.example",
  "iat": 1780272000,
  "exp": 1780272300,
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "pUbLiCKeY123pUbLiCKeY123pUbLiCKeY123",
      "y": "pUbLiCKeY456pUbLiCKeY456pUbLiCKeY456"
    }
  },
  "email": "demo@example.com",
  "email_verified": true
}

Onderteken de payload met uw privésleutel en een ondersteund algoritme. Bijvoorbeeld met jose in Node.js:

const evtJwt = await new SignJWT(evtPayload)
   .setProtectedHeader({
     alg: "EdDSA",
     kid: PRIVATE_KEY_JWK.kid, // Key ID corresponding to our JWKS keys
     typ: "evt+jwt", // Standard Token Type for EVTs
   })
   .sign(privateKey);

 // Standard SD-JWT compatibility requires appending a trailing tilde "~"
 // to separate the signed token from the key binding section.
 const issuanceToken = `${evtJwt}~`;

Voorbeeld van een succesvolle reactie (HTTP 200):

{
  "issuance_token": "tOkEn123tOkEn123tOkEn123...~"
}

Overwegingen bij een Origin-proef.

Origin-tests zijn experimenten om feedback te verzamelen, dus uw input is cruciaal als u deelneemt als relying party of als identity provider. Om problemen te melden, kunt u de volgende GitHub-repositories gebruiken:

• Browser Email Verification API: WICG/email-verification
• E-mailverificatieprotocol: dickhardt/email-verification

Als je fouten tegenkomt in de Chrome-implementatie, meld deze dan bij de betreffende component:

• Nieuw probleem: Chromium > Blink > Identity > EVP

Het inschakelen van de Origin Trial-functionaliteit wordt per reactie beheerd door de OT-token die u toevoegt. Dit betekent dat u nauwkeurige controle hebt als u de functionaliteit wilt beperken tot een deel van uw gebruikers. Als u bijvoorbeeld al een A/B-testomgeving hebt, kunt u de Origin Trial daarin integreren voor een gecontroleerde experimentele populatie. Als u daarentegen een bètatest- of vroege previewgroep hebt, wilt of moet u de functie mogelijk voor hen inschakelen. Controleer in dat geval het opgegeven e-mailadres voordat u de token uitgeeft of valideert.

Origin-tests hebben ook verkeerslimieten om te voorkomen dat websites te veel gebruikmaken van de functie vóór de lancering. De issuer-API is in ontwikkeling en je kunt achterwaarts incompatibele wijzigingen verwachten, samen met updates van de Chrome-gebruikersinterface.

We zullen verdere updates plaatsen op dit blog en op de mailinglijst evp-announce@chromium.org naarmate de ontwikkeling vordert.