Solo indirizzi confermati: niente accesso con un'e-mail non confermata
Dal 3 ottobre 2026 nessuna applicazione riceve un account EAuth con un indirizzo non confermato. Perché, e cosa cambia per le integrazioni.
Dal 3 ottobre 2026 EAuth non consegna a nessuna applicazione un account il cui indirizzo e-mail non sia stato confermato. Un codice di autorizzazione viene emesso solo dopo che la persona ha aperto un link inviato a quell'indirizzo, quindi in un token che proviene da un accesso email_verified è sempre true.
Anche prima la registrazione inviava un link, ma l'accesso proseguiva senza aspettarlo, e l'ID token riportava email_verified: false finché il link non veniva aperto. Era onesto e, nella pratica, non bastava. Ecco perché l'ho cambiato, cosa vedono ora la persona e l'applicazione, e quanto costa.
Un indirizzo non confermato è un nome che chiunque può digitare
Chiunque può registrarsi con qualsiasi indirizzo. Finché il link non viene aperto, l'indirizzo sull'account è un'affermazione di chi l'ha digitato, non un fatto su chi legge quella casella.
OpenID Connect ha un claim proprio per questo: email_verified è vero quando il provider «ha adottato misure concrete per assicurarsi che questo indirizzo e-mail fosse controllato dall'utente finale». La specifica mette l'informazione nel token. Non può obbligare nessuno a leggerla. Un'applicazione che lega qualcosa all'indirizzo senza verificare il claim consegna i privilegi di quell'indirizzo a chi l'ha registrato per primo:
- Inviti e cose condivise. Un'applicazione che invita persone in un progetto, condivide un documento o assegna un ruolo in base all'indirizzo lo consegna all'account che porta quell'indirizzo. Se quell'account appartiene a qualcuno che ha digitato l'indirizzo di un estraneo, l'invito va a lui.
- Organizzazioni per dominio. EAuth permette a un'organizzazione con un dominio verificato di accogliere tutti coloro il cui indirizzo è in quel dominio. Questo richiedeva già un indirizzo confermato, perché un indirizzo che chiunque può digitare non prova che si lavori in un'azienda. Un'applicazione che faceva qualcosa di simile per conto proprio non aveva questo controllo, a meno di scriverselo.
- Account creati prima del loro proprietario. Sudhodanan e Paverd hanno studiato il fenomeno con il nome di account pre-hijacking: un attaccante crea un account con l'indirizzo della vittima prima che la vittima arrivi, ed entra non appena la vittima comincia a usarlo. Hanno trovato almeno 35 servizi popolari su 75 vulnerabili all'una o all'altra delle sue forme.
Ogni applicazione poteva verificare email_verified da sé, e la maggior parte non ci ha mai guardato. Fare il controllo una volta sola, in EAuth, significa che ogni applicazione ne beneficia. Le linee guida di OWASP sull'autenticazione riassumono la regola in una riga: un indirizzo e-mail può fungere da nome utente a patto che venga verificato durante la registrazione.
Cosa vede la persona
La registrazione invia un'e-mail con l'oggetto «Confirm your email address for» seguito dal nome dell'applicazione. Il link funziona una volta, per 24 ore, e porta con sé la strada per tornare all'accesso che la persona aveva avviato.
Se torna all'applicazione senza averlo aperto, la persona non riceve un codice ma una pagina con i colori dell'applicazione, «Confirm your email address». La pagina spiega che l'applicazione potrà usare l'account una volta confermato l'indirizzo, e che il link riporta qui. Il suo pulsante, «Send a new link», apre la pagina dell'account, che invia un nuovo link con la stessa strada del ritorno. La strada del ritorno può puntare solo a una pagina di EAuth stesso, la stessa regola che segue un accesso quando riprende, quindi il link non può diventare un redirect verso un altro posto.
Aprire il link conferma subito l'indirizzo e mostra «Address confirmed» con un pulsante «Continue» che riporta all'accesso. L'applicazione riceve il suo codice, oppure prima compare la schermata di consenso, se la persona non ha ancora accettato i suoi scope.
La conferma all'apertura, senza un ulteriore clic, è voluta. Gli scanner della posta seguono i link, e per una conferma va bene: chi può aprire la posta inviata all'indirizzo è proprio la persona di cui si parla. Un link per reimpostare la password, una volta aperto, mostra soltanto un modulo, perché uno scanner non deve poterlo consumare.
La pagina dell'account invia al massimo tre link all'ora per account; una quarta richiesta lo comunica e dice quando riprovare. I link sono 256 bit casuali, salvati solo come digest. Un link conferma solo finché l'account ha ancora l'indirizzo a cui è stato inviato. Anche impostare una nuova password tramite un link di ripristino vale come conferma, perché dimostra la stessa cosa.
Cosa vede l'applicazione
- Un codice solo dopo la conferma.
email_verifiedètruein ogni ID token proveniente da un accesso. prompt=nonerestituisceinteraction_required, con la descrizione «The account's email address is not confirmed yet.» È l'errore che OpenID Connect definisce per una richiesta che non può concludersi senza mostrare una pagina. Un accesso silenzioso che lo riceve dovrebbe ripiegare su un normale redirect, dove la persona vede la pagina di conferma.user.createdarriva prima della conferma. Il webhook parte alla registrazione conemail_verified: false, perché una persona che chiude la scheda dopo essersi registrata non arriva mai allo scambio del token. Non lo tratti come un accesso.- Gli account single sign-on sono confermati dal provider. Un account creato tramite il provider SAML di un'organizzazione è confermato al momento della creazione. Se esisteva un account non confermato con lo stesso indirizzo, l'account passa alla persona di cui il provider si fa garante: password, passkey e secondo fattore vengono rimossi, i refresh token terminano e l'applicazione riceve
session.revokedcon il motivo «account claimed through single sign-on». - Gli account importati mantengono il loro flag. Un account importato con
email_verifiedfalse viene fermato al primo accesso con la stessa pagina e conferma da lì. Uno importato come true accede come prima. - Un indirizzo corretto torna non confermato. Cambiare l'indirizzo di una persona nella console annulla la conferma, a meno che non siano cambiate solo maiuscole e minuscole.
- Anche un refresh controlla. Ogni token che EAuth emette, compreso uno rinnovato, è per un account con l'indirizzo confermato. Il refresh token di un account il cui indirizzo non è più confermato, per esempio perché corretto nella console, viene rifiutato con
invalid_grant, e la persona deve accedere di nuovo. Un access token emesso prima scade entro la sua durata, 15 minuti di default.
TestAnApplicationGetsOnlyConfirmedAddresses percorre tutto questo: registrazione, ritorno alla pagina di conferma senza codice, interaction_required con prompt=none, invio di un nuovo link dalla pagina dell'account con verifica che sia diverso dal primo, apertura, «Continue» che punta a /authorize e infine il codice.
Quanto costa
Un passaggio in più per ogni nuova persona, e avviene fuori dall'applicazione, in una casella di posta. Il recapito della posta ora fa parte della registrazione: un'e-mail che arriva in ritardo, finisce nello spam o va a un indirizzo digitato male ferma una persona sulla porta, e tre nuovi link all'ora sono il massimo che può chiedere. Qualcuno si arrenderà lì.
Penso che sia lo scambio giusto per un sistema di account su cui costruiscono altre applicazioni. L'alternativa era che ogni applicazione decidesse da sola se un indirizzo significa qualcosa, e che la maggior parte decidesse non decidendo. La regola vale anche per la nostra console, che accede dalla stessa porta.
Fonti
- OpenID Connect Core 1.0: Standard Claims (email_verified) and Authentication Error Response (interaction_required), OpenID Foundation, consultato il
- Authentication Cheat Sheet, OWASP, consultato il
- Pre-hijacked accounts: An Empirical Study of Security Failures in User Account Creation on the Web, USENIX Security 2022, Avinash Sudhodanan and Andrew Paverd, consultato il
Scritto da Samuel Krauss, Founder. Archiviato in eauth, openid-connect, email-verification, authentication, security, registration.
Tradotto dall’inglese. Leggi l’originale inglese