Tester le protocole de validation de l'adresse e-mail avec un test d'origine

Rowan Merewood

Publié le 8 juillet 2026, dernière mise à jour le 5 octobre 2026

Lorsque vous collectez une adresse e-mail lors d'une inscription, d'une connexion, d'un abonnement, d'un paiement, d'une récupération de compte ou d'un autre processus, il est courant de confirmer que l'adresse e-mail appartient à la personne qui la saisit. Les méthodes de validation existantes, comme les mots de passe à usage unique (OTP) ou les liens de validation de l'adresse e-mail (liens magiques), obligent l'utilisateur à quitter votre site. Ce processus perturbateur peut augmenter le risque que l'utilisateur, qu'il s'agisse d'un humain ou d'un agent, abandonne complètement sa session et ne termine jamais son processus d'authentification.

L'API Email Verification est une proposition qui permet au navigateur de communiquer directement avec le fournisseur de messagerie pour vérifier que l'utilisateur est bien le propriétaire de l'adresse e-mail. Les utilisateurs sélectionnent une adresse e-mail dans la suggestion de saisie automatique ou de saisie semi-automatique du navigateur, envoient le formulaire, et le site valide l'adresse e-mail auprès du fournisseur sans envoyer d'e-mail ni interrompre le parcours de l'utilisateur.

Démo de la requête utilisateur de l'API Email Verification
Démonstration de l'invite utilisateur de l'API Email Verification

La collecte d'adresses e-mail est un point de conversion essentiel dans le parcours d'un utilisateur. Chrome aimerait recevoir des commentaires sur la proposition de la part des sites qui souhaitent valider des adresses e-mail, des fournisseurs de messagerie qui peuvent effectuer la validation et des utilisateurs qui ont déjà effectué le processus. Vous pouvez vous inscrire à l'Origin Trial dès aujourd'hui et suivre les instructions d'implémentation ici. Pour obtenir des informations générales sur la configuration des essais Origin Trial, consultez Premiers pas avec les essais Origin Trial.

Vous pouvez essayer le flux avec un compte de démonstration :

Processus de validation de l'adresse e-mail

Les sections suivantes expliquent ce que vous et vos utilisateurs devez faire pour démarrer le flux de validation des adresses e-mail, ainsi que l'ensemble du workflow lorsque vous utilisez le protocole de validation des adresses e-mail.

Termes clés

Voici les termes clés de l'API Email Verification :

  • Validateur : site qui collecte l'adresse e-mail et souhaite la valider. Le vérificateur est également appelé partie de confiance.
  • Fournisseur de messagerie : service fournissant l'adresse e-mail de l'utilisateur, par exemple gmail.com.
  • Émetteur : service qui gère le compte pour l'adresse e-mail de l'utilisateur, par exemple accounts.google.com. L'émetteur est également appelé fournisseur d'identité.

Dans certains cas, le fournisseur de messagerie et l'émetteur peuvent opérer à partir du même domaine. Toutefois, il est important de faire la différence entre le fait d'avoir une adresse e-mail et le fait d'avoir une session active pour le compte associé.

Architecture du flux de validation de l'adresse e-mail
Architecture du parcours de validation de l'adresse e-mail

Prérequis

  • L'utilisateur doit être connecté à son fournisseur de messagerie ou à l'émetteur dans le même profil de navigateur. Par exemple, s'ils utilisent Gmail, ils doivent être connectés à leur compte Google.
  • En tant que site participant à la validation, vous devez vous inscrire à l'Origin Trial et fournir le jeton sur la même page que votre formulaire d'adresse e-mail.

  • L'utilisateur doit sélectionner son adresse e-mail dans le menu déroulant de saisie automatique.

    • Si l'utilisateur a déjà saisi une adresse e-mail dans le champ, elle lui sera proposée grâce à la saisie semi-automatique.

    • Si l'utilisateur a ajouté son adresse e-mail à l'aide des paramètres Chrome "Saisie automatique et mots de passe" (chrome://settings/autofill), elle sera proposée à l'aide de la saisie automatique.

  • La première fois qu'un utilisateur fournit une adresse e-mail pour la validation, il voit une invite d'autorisation. Cela ne se produit qu'une seule fois par adresse e-mail.

Une fois que l'utilisateur a cette session active dans son navigateur, il peut commencer le processus :

  1. Dans un formulaire comportant un champ d'adresse e-mail, l'utilisateur sélectionne son adresse e-mail dans le menu déroulant de saisie semi-automatique. Le site du validateur fournit un champ masqué dans le formulaire avec un nonce par instance pour valider cette requête.

  2. Le navigateur récupère ensuite l'enregistrement DNS de validation de l'adresse e-mail pour le domaine de messagerie. Cela redirige le navigateur vers l'émetteur. L'émetteur confirmera ensuite qu'il dispose d'une session active pour cette adresse e-mail.

  3. L'émetteur fournira ensuite son jeton de validation d'adresse e-mail (EVT, Email Verification Token) pour l'adresse. Le navigateur combine ces éléments dans un JWT lié à une clé avec l'EVT, l'origine du site et le nonce du formulaire de saisie.

  4. Lorsque le formulaire est envoyé, le package EVT est ajouté au champ masqué et envoyé au site.

  5. Le site de validation vérifie ensuite chacun de ces détails : l'adresse e-mail attendue, le nonce et les signatures du navigateur et de l'émetteur.

  6. L'utilisateur voit une petite notification l'informant que son fournisseur de messagerie a validé son adresse.

Ce processus permet au site de validation de confirmer que l'adresse e-mail est valide et appartient à l'utilisateur actuel. Le site peut donc éviter d'envoyer un e-mail de validation.

Les utilisateurs peuvent gérer leurs adresses e-mail validées sous Paramètres > Saisie automatique et mots de passe > Coordonnées > Adresse e-mail validée (ou ouvrir chrome://settings/contactInfo).

Points à prendre en compte pour les cas d'utilisation

La validation de l'adresse e-mail est une amélioration progressive de votre flux existant. Elle permet à l'utilisateur de ne pas avoir à quitter votre site pour récupérer un code OTP ou cliquer sur un lien. Les sites peuvent ajouter les champs de validation de l'adresse e-mail à tous les formulaires concernés, comme les formulaires de connexion, d'inscription à la newsletter, de création de compte et de récupération de mot de passe. L'EVP n'est déclenché que si le navigateur le prend en charge. Si aucun code n'est reçu lors de l'envoi ou si l'une des étapes de validation échoue, vous pouvez revenir à votre flux de confirmation par e-mail par défaut. Cela signifie également qu'il n'y a pas de détection de fonctionnalité pour l'API. Le site de validation traite l'EVT comme facultatif et le traite s'il est présent dans la requête.

La validation de l'adresse e-mail confirme que l'utilisateur dispose d'une session active auprès du fournisseur de son adresse e-mail. Elle ne valide pas que votre e-mail est bien parvenu à l'utilisateur. Vous pouvez toujours envoyer des e-mails de bienvenue ou d'intégration existants, et vous pouvez ou devez inviter l'utilisateur à vérifier ses paramètres de spam.

Implémenter le site du validateur

Pour en savoir plus, vous pouvez parcourir le code de démonstration de bout en bout et consulter les étapes de validation dans les propositions d'API Email Verification et de protocole Email Verification.

Configurer les champs du formulaire

Assurez-vous que les champs de votre formulaire comportent les attributs appropriés :

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

Définissez les attributs type et autocomplete de l'entrée email sur email pour permettre au navigateur de proposer la saisie semi-automatique de l'adresse e-mail.

Le nouveau champ hidden sera renseigné avec le jeton de validation de l'adresse e-mail lors de l'envoi du formulaire. Les attributs nécessaires sont les suivants :

  • Définissez type="hidden", car ce champ ne nécessite aucune saisie de la part de l'utilisateur.
  • Définissez nonce="rAnD0m-VaLuE". Le site doit fournir un nonce unique lié à la session pour valider l'envoi du formulaire.
  • Définissez autocomplete="email-verification-token". Le navigateur utilise cet attribut pour identifier le champ à remplir.

Validez les éléments de votre formulaire en consultant le panneau "Réseau" dans les outils de développement. Lorsque vous sélectionnez une adresse e-mail, le navigateur déclenche les requêtes DNS et de recherche de compte ultérieures pour le fournisseur de messagerie et l'émetteur. Il s'agit de requêtes internes au navigateur. Votre site ne reçoit rien tant que le formulaire n'est pas envoyé.

Valider l'EVT

Pour valider chaque composant du package EVT, vous devez suivre cinq étapes.

  1. Analysez le jeton.
  2. Validez les valeurs attendues.
  3. Validez la liaison de touches.
  4. Validez l'enregistrement DNS.
  5. découvrir l'émetteur et valider la signature EVT.

1. Analyser le jeton

Les données brutes de l'envoi du formulaire contiennent l'EVT et les revendications signées dans un jeton Web JSON à divulgation sélective (SD-JWT+KB) séparé par un tilde (caractère ~). Vous devrez les séparer et décoder les en-têtes et les charges utiles de Javascript Object Signing and Encryption (JOSE), par exemple en utilisant jose pour Node.js.

Si example.com valide demo@gmail.com, la charge utile décodée ressemble à l'exemple suivant :

{
  "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. Valider les valeurs attendues

Vérifiez que les valeurs de base de la charge utile correspondent aux valeurs que vous avez fournies :

  • Vérifiez que email_verified est défini sur true.
  • Vérifiez que email correspond à l'adresse e-mail indiquée dans votre formulaire.
  • Vérifiez que nonce correspond au nonce fourni dans votre formulaire.
  • Vérifiez que aud correspond à l'origine de votre site.
  • Vérifiez que iat comporte un code temporel relativement récent, par exemple après l'affichage du formulaire.

3. Valider la liaison de touches

Le navigateur crée une clé éphémère temporaire pour la transaction afin de confirmer qu'il a signé le jeton. Extrayez cette clé de la revendication cnf (confirmation) dans l'EVT, puis utilisez-la pour valider le jeton JWT lié à la clé.

Calculez ensuite le hachage attendu et comparez-le à la revendication sd_hash. L'exemple Node.js suivant montre comment effectuer ce calcul :

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

4. Valider l'enregistrement DNS

Vérifiez l'enregistrement DNS _email-verification pour le domaine de l'adresse e-mail. Par exemple, pour demo@gmail.com, interrogez l'enregistrement _email-verification.gmail.com TXT. Pour ce fournisseur, la requête renvoie l'emplacement du fournisseur de compte, c'est-à-dire accounts.google.com.

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

5. Découvrir l'émetteur et valider la signature EVT

Assurez-vous que l'émetteur diffuse la ressource /.well-known/email-verification, qui fournit les points de terminaison pour l'émission du jeton, la clé Web JSON (JWK) pour le site et les algorithmes de signature compatibles.

$ 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"]
}

Utilisez les JWK pour valider le jeton JWT EVT que vous avez extrait du jeton. La plupart des bibliothèques JOSE fournissent des fonctions pour gérer cette validation.

Si les cinq étapes aboutissent, vous avez validé l'adresse e-mail auprès du fournisseur. Si ce n'est pas le cas, revenez à votre flux habituel et envoyez un e-mail de confirmation à l'utilisateur.

Implémenter le service de fournisseur et d'émetteur d'e-mails

Pour en savoir plus, vous pouvez parcourir le code de démonstration du fournisseur d'adresse e-mail fictive et consulter les étapes de l'émetteur dans les propositions d'API Email Verification et de protocole Email Verification.

En tant qu'émetteur, vous n'avez pas besoin de vous inscrire à l'essai Origin Trial ni de fournir de jeton, car le comportement du navigateur est déclenché par le site de la partie de confiance. Il vous suffit de vous assurer que les points de terminaison attendus sont en place pour répondre à ces demandes.

Configurer la découverte de l'émetteur

Pour permettre aux navigateurs de découvrir automatiquement vos points de terminaison de validation lorsqu'une adresse e-mail appartenant à votre domaine est sélectionnée, exposez votre configuration à l'aide du DNS et d'un point de terminaison HTTP .well-known.

Configurer un enregistrement de délégation DNS

Configurez un enregistrement DNS TXT sur votre domaine de messagerie qui délègue l'autorité de validation à votre identifiant d'émetteur. Ces identifiants peuvent utiliser le même domaine en fonction de votre infrastructure.

Format de l'enregistrement : _email-verification.<email-domain>

Exemple de fichier de zone :

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

Héberger un point de terminaison .well-known/email-verification

Hébergez un fichier de métadonnées JSON sur le domaine de votre émetteur, sous le chemin d'accès /.well-known/. Ce fichier décrit vos capacités d'émission et les algorithmes de signature cryptographique compatibles avec votre infrastructure.

Point de terminaison : https://<issuer-domain>/.well-known/email-verification

Exemple de réponse :

{
  "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"]
}

Héberger un point de terminaison .well-known/web-identity

Ressource JSON .well-known supplémentaire que vous avez peut-être déjà implémentée dans l'API Federated Credentials (FedCM). Vous y trouverez des liens vers le point de terminaison de vos comptes et l'URL de connexion.

Point de terminaison : https://<domain>/.well-known/web-identity

Exemple de réponse :

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

Utiliser un point de terminaison de comptes

Le point de terminaison des comptes de l'API FedCM fournit actuellement une liste des comptes connectés. L'exemple suivant montre une réponse minimale. Pour en savoir plus, consultez le guide d'implémentation du fournisseur d'identité.

Point de terminaison : tel que spécifié dans .well-known/web-identity

Voici un exemple de réponse :

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

Intégrer l'API Login Status

L'utilisateur doit avoir une session active avec le fournisseur, et vous devez le signaler au navigateur avec l'API Login Status.

Lorsqu'un utilisateur se connecte ou se déconnecte, diffusez l'en-tête de réponse HTTP correspondant :

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

Vous pouvez également mettre à jour l'état à l'aide de JavaScript dans le contexte de votre application Web :

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

Traiter les demandes d'émission

Votre issuance_endpoint reçoit une requête POST application/x-www-form-urlencoded contenant le request_token.

Les sections suivantes présentent le processus complet de traitement des demandes d'émission.

1. Valider la demande d'émission

Analysez et validez les charges utiles de navigateur entrantes :

  • Méthode : POST
  • Validation de la session : validez les cookies first party de l'utilisateur session/authentication transmis avec la requête pour vous assurer qu'un contexte d'identité actif et autorisé existe.
  • Vérification des paramètres : extrayez le paramètre request_token (un jeton JWT signé généré par le navigateur). Vérifiez qu'il contient la clé publique éphémère attendue, l'adresse e-mail cible, l'audience correcte et un code temporel valide.

Le jeton décodé devrait se présenter comme suit :

{
  "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. Répondre avec un jeton

Une fois la session et le jeton de requête validés, générez un jeton JWT (SD-JWT) à divulgation sélective signé à l'aide de la charge utile :

{
  "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
}

Signez la charge utile à l'aide de votre clé privée et de l'algorithme compatible. Par exemple, en utilisant jose dans 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}~`;

Exemple de réponse positive (HTTP 200) :

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

Points à prendre en compte pour les essais Origin Trial

Les essais Origin Trial sont des tests permettant de recueillir des commentaires. Votre avis est donc essentiel si vous participez en tant que partie de confiance ou fournisseur d'identité. Pour signaler des problèmes, utilisez les dépôts GitHub suivants :

Si vous rencontrez des bugs dans l'implémentation de Chrome, signalez-les au niveau du composant :

L'activation de la fonctionnalité d'Origin Trial est contrôlée par réponse, en fonction de l'inclusion du jeton OT. Cela signifie que vous disposez d'un contrôle précis si vous préférez limiter la fonctionnalité à une partie de vos utilisateurs. Par exemple, si vous disposez déjà d'un framework de tests A/B, vous pouvez y intégrer l'essai Origin Trial pour une population de test contrôlée. Si vous disposez d'un groupe d'utilisateurs pour les tests bêta ou les aperçus anticipés, vous pouvez ou devez activer la fonctionnalité pour eux. Dans ce cas, vérifiez l'adresse e-mail fournie avant d'émettre ou de valider le jeton.

Les essais Origin Trial sont également soumis à des limites de trafic afin de minimiser le nombre de sites qui s'appuient sur la fonctionnalité avant son lancement. L'API émetteur est en cours de développement. Vous devez vous attendre à des modifications incompatibles avec les versions antérieures, ainsi qu'à des mises à jour de l'expérience utilisateur Chrome.

Nous publierons d'autres informations sur le blog et sur la liste de diffusion evp-announce@chromium.org à mesure que le développement progressera.