Aggiornamenti alla verifica dell'email, ottobre 2026

Rowan Merewood

Pubblicato: 5 ottobre 2026

Man mano che la prova dell'origine della verifica email continua, abbiamo apportato ulteriori aggiornamenti in base ai tuoi feedback. Non prevediamo ulteriori modifiche che potrebbero causare problemi e ci stiamo preparando a rilasciare la funzionalità. Abbiamo anche lanciato una nuova sezione di documentazione per la verifica delle email con sezioni dedicate per verificatori ed emittenti.

La prova dell'origine della verifica email è iniziata in Chrome 150 su computer. In seguito ai feedback degli sviluppatori e ai test nell'ecosistema, stiamo continuando a perfezionare l'implementazione. Questo post tratta gli aggiornamenti di Chrome 154, tra cui il supporto di Android, le prove dell'origine di terze parti, la gestione della scoperta delle chiavi durante la convalida dei token e un aggiornamento dell'intestazione per i provider di posta elettronica.

Aggiornamenti rivolti agli utenti

Modifiche all'interfaccia utente o al comportamento rivolto agli utenti.

Supporto di Chrome su Android

A partire da Chrome 154, Chrome per Android supporta la verifica dell'email. I verificatori o i fornitori non devono apportare modifiche perché l'API o il protocollo rimangono invariati. Si applicano gli stessi prerequisiti, incluso il requisito che l'utente deve aver eseguito l'accesso al proprio provider email nel browser.

Gli utenti possono accedere alle impostazioni in Impostazioni > Indirizzi e altro > Email verificata.

Aggiornamenti per i verificatori

Modifiche per i siti che raccolgono e verificano le email.

Prove dell'origine di terze parti

A partire da Chrome 154, le prove di origine di terze parti sono supportate per la verifica dell'email (vedi problema 534377131). Se fornisci uno script incorporato o un SDK Identity, ora puoi registrarti per un token di prova di terze parti e inserirlo nelle pagine che ospitano lo script. I siti web che incorporano il tuo script non devono registrare token di prova dell'origine separati.

Esiste un avviso importante: il registrante dell'origin trial e l'emittente devono essere dello stesso sito. Nello specifico, l'origine registrata per la prova deve corrispondere al dominio dell'emittente.

Configurazione supportata:

  • Dominio dell'emittente: issuer.example
  • OT registrant: https://issuer.example
  • Origine JavaScript: https://issuer.example (o https://app.issuer.example con corrispondenza dei sottodomini)

Configurazioni non supportate:

  • Registrante del sottodominio: il dominio dell'emittente è issuer.example, ma il registrante OT è https://app.issuer.example.
  • Registrante cross-site: il dominio dell'emittente è issuer.example, ma il registrante OT è https://different.example.

Gestisci kid facoltativo in EVT

Durante la convalida del token di verifica email (EVT), il server recupera il set di chiavi web JSON (JWKS) del provider per verificare la firma crittografica dell'emittente. Le chiavi includono facoltativamente un identificatore di chiave kid, che è anche facoltativamente incluso nel JWT che indica quale chiave è stata utilizzata per firmare il token. Se il token non include l'attestazione kid (ad esempio, con Gmail), scorri le chiavi per trovare quella corretta. La documentazione e la demo mostrano il codice per farlo.

Restituzione della rivendicazione email esattamente come fornita

A partire da Chrome 156, l'indirizzo email nel token verrà restituito esattamente come fornito nell'invio del modulo (vedi problema 549217427). In precedenza, gli emittenti potrebbero aver restituito l'indirizzo email canonico dell'account (ad esempio, restituendo First.Last@example.com quando l'invio del modulo conteneva first.last@example.com). Tieni presente che è sempre consigliabile utilizzare un confronto senza distinzione tra maiuscole e minuscole per l'email restituita, quindi questa non dovrebbe essere una modifica che causa interruzioni.

Aggiornamenti dei fornitori

Modifiche per i provider email.

Restituzione della rivendicazione email esattamente come fornita

Dal lato del fornitore, questo requisito è più rigoroso: se il fornitore non restituisce l'email esattamente come fornita, Chrome rifiuterà il token. In questo modo si evita di esporre più dati di quelli che verrebbero rivelati dall'invio di un'email di conferma. Convalida l'email in arrivo rispetto all'utente che ha eseguito l'accesso per una corrispondenza nello stesso modo in cui gestisci la consegna delle email.

Ridenominazione di Sec-Fetch-Dest in email-verification

A partire da Chrome 154, l'intestazione Sec-Fetch-Dest inviata nelle richieste di emissione del token è stata aggiornata per utilizzare un trattino:

  • Chrome 154 o versioni successive: Sec-Fetch-Dest: email-verification
  • Chrome 153: Sec-Fetch-Dest: emailverification

Questa modifica standardizza l'identificatore della destinazione di recupero con le convenzioni di denominazione della piattaforma web (vedi problema 546618576).

Se l'endpoint di emissione convalida l'intestazione Sec-Fetch-Dest (consigliato per proteggersi da CSRF e contesti di richiesta non intenzionali), aggiorna il controllo in modo che accetti email-verification. Per evitare interruzioni durante i rollout del browser, accetta entrambi i valori durante la transizione.

Risorse e feedback