Verifica email

L'API Email Verification è una proposta che consente al browser di comunicare direttamente con il provider email per verificare che l'utente sia il proprietario dell'indirizzo email. Gli utenti inseriscono il proprio indirizzo email, inviano il modulo e il sito verifica il token di verifica dell'email firmata dal browser con il provider senza inviare un'email o interrompere il flusso dell'utente.

Quando raccolgono un indirizzo email durante la registrazione, l'accesso, il pagamento, l'iscrizione alla newsletter o il recupero dell'account, i siti in genere confermano che la persona che invia il modulo controlla l'indirizzo. I metodi di verifica esistenti richiedono agli utenti di uscire dal tuo sito, cambiare app per controllare la posta in arrivo, copiare un OTP o fare clic su un link di verifica. Questa interruzione aumenta l'abbandono e l'interruzione della sessione sia per gli utenti umani sia per gli agenti automatizzati. Gli utenti spesso riscontrano problemi con i metodi di verifica esistenti, come email in ritardo, link scaduti o codici non riconosciuti.

Demo del prompt utente di verifica email
Demo del prompt utente per la verifica email

La verifica email funge da potenziamento progressivo del flusso esistente:

  • Nessuna interruzione: la verifica avviene in background mentre l'utente compila il modulo.
  • Nessun rilevamento delle funzionalità richiesto: i siti aggiungono un input email e un input token nascosto ai loro moduli. Se il browser o il provider non supporta la verifica dell'email o se la verifica non va a buon fine, il sito torna al flusso di conferma dell'email predefinito.
  • Ridurre al minimo i rischi di phishing: non c'è codice da copiare né la possibilità di inviare l'utente a un sito falso.

Puoi testare il flusso nella demo:

Considerazioni sugli origin trial

Le origin trial sono esperimenti per raccogliere feedback, quindi il tuo contributo è fondamentale se partecipi in qualità di relying party o di fornitore di identità. Per segnalare problemi, utilizza i seguenti repository GitHub:

Se riscontri bug nell'implementazione di Chrome, segnala un problema nel componente seguente:

Controlli la funzionalità di origin trial in base alla risposta includendo il token di origin trial. In questo modo puoi limitare la funzionalità a un segmento specifico di utenti, ad esempio un gruppo di test A/B. In alternativa, se hai un gruppo di utenti per i test beta o l'anteprima, potresti voler o dover attivare la funzionalità per loro. In questo caso, esegui il controllo in base all'indirizzo email fornito prima di emettere o convalidare il token.

Le prove dell'origine hanno anche limiti di traffico per ridurre al minimo i siti che si affidano alla funzionalità prima del lancio. L'API emittente è in fase di sviluppo e devi aspettarti modifiche incompatibili con le versioni precedenti, oltre ad aggiornamenti dell'esperienza utente di Chrome.

Segui gli aggiornamenti sul blog qui e nella mailing list evp-announce@chromium.org man mano che lo sviluppo procede.

Flusso di verifica email

Le sezioni seguenti spiegano i termini chiave e i passaggi del protocollo quando si utilizza l'API Email Verification.

Termini chiave

I termini chiave per l'API Email Verification sono:

  • Verificatore: il sito che raccoglie l'indirizzo email e vuole verificarlo. Il verificatore è anche chiamato parte autorizzata.
  • Provider email: il servizio che fornisce l'indirizzo email dell'utente, ad esempio gmail.com.
  • Emittente: il servizio che gestisce l'account per l'email dell'utente, ad esempio accounts.google.com. L'emittente è chiamato anche provider di identità.

In alcuni casi, il fornitore di servizi email e l'emittente operano dallo stesso dominio. Tuttavia, è importante distinguerli perché l'API Email Verification utilizza la sessione attiva nel browser con il provider di identità come metodo di verifica. Ad esempio, per la verifica example@gmail.com l'utente deve aver eseguito l'accesso a google.com con quell'account nello stesso browser.

Flusso del protocollo

Architettura del flusso di verifica email
Architettura del flusso di verifica email
  1. Presentazione del modulo: la relying party pubblica un modulo HTML contenente un <input type="email"> e un input nascosto contrassegnato con autocomplete="email-verification-token" e un nonce univoco per istanza.
  2. Inserimento email: quando l'utente inserisce un indirizzo email, selezionando un suggerimento di compilazione automatica o digitando o incollando e uscendo dal campo (blur), il browser attiva la verifica in background.
  3. Rilevamento e sessione: il browser esegue una query sul record TXT DNS per _email-verification.<email-domain> per rilevare l'origine dell'emittente autorizzata del provider, quindi verifica se l'utente ha una sessione attiva utilizzando la configurazione .well-known/web-identity dell'emittente e gli endpoint degli account FedCM. Se il dominio non pubblica un record EVP o non esiste una sessione attiva, il browser interrompe la verifica senza chiedere all'utente.
  4. Emissione del token: il browser rileva il issuance_endpoint del fornitore da .well-known/email-verification, crea una coppia di chiavi effimere e invia una richiesta HTTP POST utilizzando HTTP Message Signatures (RFC 9421) con i cookie di sessione proprietari dell'emittente e l'indirizzo email di destinazione per ricevere un token di verifica email firmato (EVT).
  5. Associazione e invio della chiave: il browser associa la firma EVT all'origine e al modulo della relying party nonce all'interno di un JWT di associazione della chiave (KB-JWT). Quando l'utente invia il modulo, Chrome compila l'input nascosto con il token combinato (<EVT>~<KB-JWT>) e mostra una piccola notifica che informa l'utente che il suo provider email ha verificato il suo indirizzo.
  6. Convalida delle rivendicazioni e della Knowledge Base: il server della relying party analizza il token <EVT>~<KB-JWT>, convalida le rivendicazioni previste (email, email_verified, aud, nonce, iat e exp) e verifica la firma del binding della chiave rispetto alla chiave pubblica effimera in cnf.jwk.
  7. DNS e chiavi pubbliche: la relying party esegue query sul record TXT DNS _email-verification.<email-domain> per verificare che corrisponda all'attestazione iss del token, quindi recupera i metadati e le chiavi pubbliche .well-known/email-verification dell'emittente da jwks_uri.
  8. Verifica EVT e completamento: la relying party verifica la firma EVT dell'emittente utilizzando la JWKS pubblica del fornitore. Se non viene ricevuto alcun token o se un passaggio di convalida non va a buon fine, il sito torna alla procedura di conferma via email esistente.

La prima volta che un utente verifica un indirizzo email, Chrome mostra una richiesta di autorizzazione (una finestra di dialogo sul computer o un riquadro inferiore su Android) prima di richiedere un token. Se concessa, questa autorizzazione viene memorizzata per indirizzo email nei siti partecipanti.

Impostazioni di Google Chrome

Gli utenti possono gestire le proprie email verificate:

  • Su computer, vai a Impostazioni > Compilazione automatica e password > Dati di contatto > Email verificata (o apri chrome://settings/contactInfo).
  • Su Android, in Impostazioni > Indirizzi e altro > Email verificata

Gli utenti possono disattivare completamente la funzionalità o gestire i singoli indirizzi email verificati.

Considerazioni sul caso d'uso

La verifica email è un potenziamento progressivo del flusso esistente che elimina la necessità per un utente di uscire dal tuo sito per recuperare un OTP o fare clic su un link. I siti possono aggiungere i campi di verifica dell'email a tutti i moduli pertinenti, come accessi, iscrizioni alla newsletter, creazione di account e recupero password. L'EVP viene attivato solo se il browser lo supporta. Se non viene ricevuto alcun codice all'invio o se uno dei passaggi di convalida non va a buon fine, puoi ripristinare il flusso di conferma via email predefinito. Ciò significa anche che non viene rilevata alcuna funzionalità per l'API; il sito di verifica considera l'EVT come facoltativo e lo elabora se è presente nella richiesta.

La verifica dell'email conferma che l'utente ha una sessione attiva con il provider del suo indirizzo email. Non verifica che la tua email sia stata ricevuta dall'utente. Potresti comunque voler inviare le email di benvenuto o di onboarding esistenti e potresti voler o dover chiedere all'utente di controllare le impostazioni dello spam.