Updates voor e-mailverificatie, oktober 2026

Rowan Merewood

Gepubliceerd: 5 oktober 2026

Nu de oorspronkelijke proefperiode voor e-mailverificatie doorgaat, hebben we verdere updates doorgevoerd op basis van uw feedback. We verwachten geen verdere ingrijpende wijzigingen en bereiden ons voor om de functie te lanceren. We hebben ook een nieuw gedeelte met documentatie gelanceerd voor e-mailverificatie met speciale gedeelten voor verificateurs en uitgevers.

De origin trial voor e-mailverificatie is gestart in Chrome 150 op desktop. Naar aanleiding van feedback van ontwikkelaars en tests in het hele ecosysteem blijven we de implementatie verfijnen. In dit bericht vind je updates van Chrome 154, waaronder Android-ondersteuning, oorsprongsproeven van derden, verwerking van sleuteldetectie tijdens tokenvalidatie en een headerupdate voor e-mailproviders.

Updates voor gebruikers

Wijzigingen in de gebruikersinterface of het gedrag van de gebruiker.

Ondersteuning voor Chrome op Android

Vanaf Chrome 154 ondersteunt Chrome voor Android e-mailverificatie. Verificateurs of aanbieders hoeven geen wijzigingen aan te brengen, omdat de API of het protocol hetzelfde blijft. Dezelfde vereisten zijn van toepassing, waaronder de vereiste dat de gebruiker in de browser moet zijn ingelogd bij de e-mailprovider.

Gebruikers kunnen hun instellingen openen via Instellingen > Adressen en meer > Geverifieerd e-mailadres.

Updates voor verificateurs

Wijzigingen voor sites die e-mails verzamelen en verifiëren.

Oorsprongstests van derden

Vanaf Chrome 154 worden proefversies van oorsprongen van derden ondersteund voor e-mailverificatie (zie issue 534377131). Als je een ingesloten script of identiteits-SDK levert, kun je je nu registreren voor een proefperiode van een token van derden en deze injecteren in pagina's die je script hosten. Websites die je script insluiten, hoeven geen afzonderlijke origin trial-tokens te registreren.

Er is een belangrijk voorbehoud: de registrant van de oorspronkelijke test en de uitgever moeten same-site zijn. De oorsprong die voor de proefperiode is geregistreerd, moet overeenkomen met het domein van de uitgever.

Ondersteunde configuratie:

  • Kaartuitgevende domein: issuer.example
  • OT-registrant: https://issuer.example
  • JavaScript-oorsprong: https://issuer.example (of https://app.issuer.example met overeenkomende subdomeinen)

Niet-ondersteunde configuraties:

  • Houder van subdomein: Het uitgevende domein is issuer.example, maar de houder van de OT is https://app.issuer.example.
  • Houder van meerdere sites: Het domein van de uitgever is issuer.example, maar de houder van de OT is https://different.example.

Gebruikersnaam optioneel kid in EVT

Als je de e-mailverificatietoken (EVT) valideert, haalt je server de json-webkeyset (JWKS) van de provider op om de cryptografische handtekening van de uitgever te verifiëren. De sleutels kunnen optioneel een kid-sleutel-ID bevatten die ook optioneel in de JWT is opgenomen om aan te geven welke sleutel is gebruikt om de token te ondertekenen. Als de claim kid niet in de token staat (bijvoorbeeld bij Gmail), itereert u door de sleutels om de juiste te vinden. In de documentatie en de demo staat de code om dit te doen.

De email-claim exact retourneren zoals verstrekt

Vanaf Chrome 156 wordt het e-mailadres in de token precies zo geretourneerd als het is ingevoerd in de formulierinzending (zie issue 549217427). Eerder retourneerden uitgevers misschien het canonieke e-mailadres van het account (bijvoorbeeld First.Last@example.com als de formulierinzending first.last@example.com bevatte). Het is altijd een goede gewoonte om een vergelijking te gebruiken die niet hoofdlettergevoelig is voor het geretourneerde e-mailadres, dus dit zou geen ingrijpende wijziging moeten zijn.

Updates voor aanbieders

Wijzigingen voor e-mailproviders.

De email-claim exact retourneren zoals verstrekt

Vanuit het oogpunt van de provider is deze vereiste strenger: als de provider de e-mail niet exact retourneert zoals deze is aangeleverd, wijst Chrome het token af. Zo wordt er niet meer informatie blootgelegd dan wanneer er een bevestigingsmail wordt gestuurd. Valideer de inkomende e-mail aan de hand van de ingelogde gebruiker op dezelfde manier als je e-mailbezorging afhandelt.

Naam van Sec-Fetch-Dest wijzigen in email-verification

Vanaf Chrome 154 is de Sec-Fetch-Dest-header die wordt gestuurd bij verzoeken voor tokenuitgifte, geüpdatet om een streepje te gebruiken:

  • Chrome 154 en hoger: Sec-Fetch-Dest: email-verification
  • Chrome 153: Sec-Fetch-Dest: emailverification

Deze wijziging standaardiseert de ID van de ophaalbestemming met de naamgevingsconventies van het webplatform (zie issue 546618576).

Als uw uitgifte-eindpunt de header Sec-Fetch-Dest valideert (aanbevolen om te beschermen tegen CSRF en onbedoelde verzoekcontexten), updatet u uw controle om email-verification te accepteren. Accepteer beide waarden tijdens de overgang om onderbrekingen tijdens de browseruitrol te voorkomen.

Bronnen en feedback