Adresses confirmées uniquement : pas de connexion sans e-mail confirmé
Depuis le 3 octobre 2026, aucune application ne reçoit de compte EAuth dont l'adresse n'est pas confirmée. Pourquoi, et ce qui change pour les intégrations.
Depuis le 3 octobre 2026, EAuth ne donne à aucune application un compte dont personne n'a confirmé l'adresse e-mail. Un code d'autorisation n'est émis qu'une fois que la personne a ouvert un lien envoyé à cette adresse : dans un token issu d'une connexion, email_verified vaut donc toujours true.
Jusque-là, l'inscription envoyait déjà un lien, mais la connexion se poursuivait sans l'attendre, et l'ID token indiquait email_verified: false tant que le lien n'avait pas été ouvert. C'était honnête et, en pratique, insuffisant. Voici pourquoi j'ai changé cela, ce que voient désormais la personne et l'application, et ce que cela coûte.
Une adresse non confirmée est un nom que n'importe qui peut taper
N'importe qui peut s'inscrire avec n'importe quelle adresse. Tant que le lien n'est pas ouvert, l'adresse du compte est une affirmation de celui qui l'a tapée, pas un fait sur la personne qui lit cette boîte.
OpenID Connect a un claim exactement pour cela : email_verified est vrai quand le fournisseur « took affirmative steps to ensure that this e-mail address was controlled by the End-User ». La spécification met l'information dans le token. Elle ne peut obliger personne à la lire. Une application qui attache quoi que ce soit à l'adresse sans vérifier le claim donne les privilèges de l'adresse à celui qui l'a enregistrée le premier :
- Invitations et éléments partagés. Une application qui invite à un projet, partage un document ou attribue un rôle par adresse le remet au compte qui porte cette adresse. Si ce compte appartient à quelqu'un qui a tapé l'adresse d'un inconnu, l'invitation lui revient.
- Organisations par domaine. EAuth permet à une organisation dont le domaine est vérifié d'accueillir toutes les personnes dont l'adresse est dans ce domaine. Cela exigeait déjà une adresse confirmée, puisqu'une adresse que n'importe qui peut taper ne prouve pas qu'on travaille dans une entreprise. Une application qui faisait quelque chose de semblable de son côté n'avait pas ce contrôle, à moins de l'avoir écrit.
- Des comptes créés avant leur propriétaire. Sudhodanan et Paverd ont étudié ce phénomène sous le nom d'account pre-hijacking : un attaquant crée un compte avec l'adresse de la victime avant qu'elle n'arrive, et y entre dès qu'elle commence à l'utiliser. Ils ont trouvé au moins 35 services populaires sur 75 vulnérables à l'une ou l'autre de ses formes.
Chaque application pouvait vérifier email_verified elle-même, et la plupart ne l'ont jamais regardé. Faire la vérification une fois, dans EAuth, signifie que chaque application en bénéficie. Les recommandations d'OWASP sur l'authentification résument la règle en une ligne : une adresse e-mail peut servir de nom d'utilisateur à condition d'être vérifiée à l'inscription.
Ce que voit la personne
L'inscription envoie un mail intitulé « Confirm your email address for » suivi du nom de l'application. Le lien fonctionne une fois, pendant 24 heures, et contient le chemin du retour vers la connexion que la personne avait commencée.
Si elle revient à l'application sans l'avoir ouvert, la personne ne reçoit pas de code mais une page aux couleurs de l'application, « Confirm your email address ». Elle explique que l'application pourra utiliser le compte une fois l'adresse confirmée, et que le lien ramène ici. Son bouton, « Send a new link », ouvre la page du compte, qui envoie un nouveau lien portant lui aussi le chemin du retour. Ce chemin ne peut mener qu'à une page d'EAuth elle-même, la même règle que suit une connexion quand elle reprend, si bien que le lien ne peut pas être détourné en redirection vers ailleurs.
Ouvrir le lien confirme l'adresse aussitôt et affiche « Address confirmed » avec un bouton « Continue » qui revient à la connexion. L'application reçoit son code, ou l'écran de consentement passe d'abord si la personne n'a pas encore accepté ses scopes.
Confirmer à l'ouverture, sans clic supplémentaire, est voulu. Les scanners de mails suivent les liens, et pour une confirmation, ce n'est pas un problème : celui qui peut ouvrir un mail envoyé à l'adresse est exactement celui dont il est question. Un lien de réinitialisation de mot de passe n'affiche qu'un formulaire à l'ouverture, parce qu'un scanner ne doit pas pouvoir le consommer.
La page du compte envoie au plus trois liens par heure et par compte ; une quatrième demande l'indique et dit quand réessayer. Les liens font 256 bits aléatoires et ne sont stockés que sous forme de condensés. Un lien ne confirme que tant que le compte a encore l'adresse à laquelle il a été envoyé. Définir un nouveau mot de passe par un lien de réinitialisation vaut aussi confirmation, puisque cela prouve la même chose.
Ce que voit l'application
- Un code seulement après confirmation.
email_verifiedvauttruedans chaque ID token issu d'une connexion. prompt=nonerenvoieinteraction_required, avec la description « The account's email address is not confirmed yet. » C'est l'erreur qu'OpenID Connect définit pour une requête qui ne peut aboutir sans afficher de page. Une connexion silencieuse qui la reçoit doit se rabattre sur une redirection normale, où la personne voit la page de confirmation.user.createdarrive avant la confirmation. Le webhook part à l'inscription avecemail_verified: false, parce qu'une personne qui ferme l'onglet après s'être inscrite n'atteint jamais l'échange de token. Ne le traitez pas comme une connexion.- Les comptes en single sign-on sont confirmés par le fournisseur. Un compte créé via le fournisseur SAML d'une organisation est confirmé à sa création. S'il existait un compte non confirmé avec la même adresse, la personne dont le fournisseur se porte garant en prend possession : son mot de passe, ses passkeys et son second facteur sont supprimés, ses refresh tokens prennent fin, et l'application reçoit
session.revokedavec le motif « account claimed through single sign-on ». - Les comptes importés gardent leur indicateur. Un compte importé avec
email_verifiedà false est arrêté à sa première connexion par la même page et confirme depuis là. Un compte importé à true se connecte comme avant. - Une adresse corrigée redevient non confirmée. Modifier l'adresse d'une personne dans la console efface la confirmation, sauf si seule la casse a changé.
- Un refresh vérifie aussi. Chaque token qu'émet EAuth, y compris un token rafraîchi, concerne un compte dont l'adresse est confirmée. Le refresh token d'un compte dont l'adresse n'est plus confirmée, par exemple après une correction dans la console, est refusé avec
invalid_grant, et la personne se reconnecte. Un access token émis avant cela expire au terme de sa durée de vie, 15 minutes par défaut.
TestAnApplicationGetsOnlyConfirmedAddresses parcourt tout cela : s'inscrire, revenir à la page de confirmation sans code, obtenir interaction_required avec prompt=none, envoyer un nouveau lien depuis la page du compte et vérifier qu'il diffère du premier, l'ouvrir, trouver « Continue » pointant vers /authorize, et enfin obtenir un code.
Ce que cela coûte
Une étape de plus pour chaque nouvelle personne, et elle se passe hors de l'application, dans une boîte mail. La distribution des mails fait désormais partie de l'inscription : un mail qui arrive en retard, atterrit dans les spams ou part vers une adresse mal tapée arrête une personne à la porte, et trois nouveaux liens par heure, c'est le maximum qu'elle peut demander. Certains abandonneront là.
Je pense que c'est le bon compromis pour un système de comptes sur lequel d'autres applications s'appuient. L'alternative, c'était que chaque application décide seule si une adresse veut dire quelque chose, et que la plupart décident en ne décidant pas. La règle s'applique aussi à notre propre console, qui se connecte par la même porte.
Sources
- OpenID Connect Core 1.0: Standard Claims (email_verified) and Authentication Error Response (interaction_required), OpenID Foundation, consulté le
- Authentication Cheat Sheet, OWASP, consulté le
- Pre-hijacked accounts: An Empirical Study of Security Failures in User Account Creation on the Web, USENIX Security 2022, Avinash Sudhodanan and Andrew Paverd, consulté le
Écrit par Samuel Krauss, Founder. Classé sous eauth, openid-connect, email-verification, authentication, security, registration.
Traduit de l’anglais. Lire l’original anglais