---
title: "EAuth passa a eauth.me, e ogni porta viene contata"
summary: "EAuth ha un dominio proprio, eauth.me, e auth.elchi.dev reindirizza lì. Con il trasloco: limiti su ogni accesso, moduli verificati e indirizzi confermati."
author: "Samuel Krauss"
author_title: "Founder"
publisher: "Elchi Studios"
published: 2026-10-03
updated: 2026-10-09
url: https://elchi.dev/it/journal/eauth-passa-a-eauth-me-e-ogni-porta-viene-contata
language: it
translation_of: https://elchi.dev/en/journal/eauth-moves-to-eauth-me
tags: ["eauth","security"]
words: 1493
---

# EAuth passa a eauth.me, e ogni porta viene contata

*Di Samuel Krauss, Founder. Pubblicato il 3 ottobre 2026.*

> EAuth ha un dominio proprio, eauth.me, e auth.elchi.dev reindirizza lì. Con il trasloco: limiti su ogni accesso, moduli verificati e indirizzi confermati.

EAuth ora ha un dominio proprio: **eauth.me**. L'issuer è `https://eauth.me`, e l'accesso e la pagina dell'account stanno sul dominio principale. Dal 3 ottobre 2026 auth.elchi.dev risponde a ogni richiesta con un redirect permanente `308` allo stesso percorso su eauth.me. Il trasloco è stato l'occasione per riprendere in mano tutto ciò che una persona tocca per entrare: ora ogni porta viene contata, i moduli dimostrano da dove arrivano, il logout richiede una prova e nessuna applicazione riceve un indirizzo che nessuno ha confermato.

## Perché EAuth ha traslocato

EAuth è nato come accesso per la nostra console e la nostra dashboard, quindi elchi.dev era la casa naturale. Un indirizzo sotto il sito di un'agenzia dice «una funzione di quel sito». EAuth è un prodotto su cui altri sviluppatori possono costruire, e riceve un indirizzo che lo dice.

C'è anche un motivo di sicurezza. I browser inviano i cookie per sito, e un sito è il dominio registrabile, non il nome host. Con auth.elchi.dev, ogni pagina su ogni sottodominio di elchi.dev era lo stesso sito della pagina che custodisce la sessione di accesso di tutti. Nessuna si è comportata male, ma è una cerchia di fiducia più ampia di quella che un servizio di accesso dovrebbe avere.

E doveva succedere prima delle passkey e del single sign-on. Una passkey appartiene a un dominio, e il browser non la propone altrove; il provider di identità di un'organizzazione si configura una volta sola con l'entity ID e l'indirizzo di risposta di EAuth. Entrambi stanno su eauth.me fin dall'inizio, quindi nessuno dei due andrà rifatto a causa di un indirizzo.

Cosa costa: un accesso in più per tutti, perché le sessioni appartenevano al vecchio host. E ogni integrazione deve indicare il nuovo issuer. Un client confronta l'issuer come stringa, i token da eauth.me dicono `https://eauth.me`, e una libreria che lo verifica, come deve, li rifiuta finché la sua impostazione non corrisponde.

## Nessuna sovrapposizione, e perché non ne serviva una

Un issuer cambiato rompe le integrazioni, e le nostre condizioni promettono un preavviso prima di un cambiamento del genere. Il piano era tenere auth.elchi.dev come issuer completo per novanta giorni. Non è servito: il giorno del trasloco, tutte le applicazioni registrate su EAuth appartenevano a Elchi Studios, e nessuno al di fuori dell'azienda aveva un account. Quindi il vecchio indirizzo reindirizza dal giorno del trasloco, e le condizioni lo dicono nella versione 1.7, clausola 2.4.

Il redirect è un `308` e non un `301`, così una richiesta di token inviata al vecchio indirizzo resta un `POST` e arriva intatta. I token che ottiene indicano `https://eauth.me`. Per la nostra console e la dashboard è bastata un'impostazione, perché ogni superficie legge l'issuer dallo stesso valore.

L'ho fatto adesso perché adesso costava poco. Con qualche centinaio di integrazioni esterne sarebbe stato un progetto di migrazione con un periodo di preavviso.

## Ogni porta viene contata

Fino a questo rilascio l'API dietro elchi.dev aveva dei rate limit, e le pagine dove le persone digitano una password no. Il calcolo che lo rendeva urgente: un secondo fattore è un codice di sei cifre, e in ogni momento vengono accettati tre codici, perché gli orologi derivano. Con la password in mano, uno script ha cinque minuti per il codice e, senza limite, migliaia di tentativi. Non è un secondo fattore, è un ritardo.

Ora ogni punto che accetta una credenziale viene contato due volte: per l'indirizzo da cui arriva una richiesta e per l'account che la richiesta nomina.

| Porta | Limite |
|---|---|
| Tentativi di accesso da un indirizzo, qualsiasi metodo | 30 al minuto |
| Password sbagliate, un account da un indirizzo | 5 in 15 minuti |
| Password sbagliate, un account da qualsiasi indirizzo | 20 in 15 minuti |
| Accessi sbagliati da un indirizzo | 50 all'ora |
| Codici sbagliati del secondo fattore, un account | 5 in 15 minuti, 20 al giorno |
| Nuovi account da un indirizzo | 10 all'ora |
| `/authorize`, per indirizzo | 60 al minuto |
| `/token`, per applicazione | 120 al minuto di default, fino a 600 nella console |

Con venti codici sbagliati al giorno, chi ha la password e nient'altro impiega in media circa 45 anni a indovinare il codice.

Quattro dettagli contano più dei numeri.

**Ogni tentativo viene contato prima di essere verificato.** Il blocco ovvio controlla il blocco, poi la password, e conta l'errore dopo. Le richieste inviate nello stesso momento passano tutte il primo passo, quindi uno script che sparava cento tentativi insieme otteneva cento tentativi. Una revisione della prima versione ha trovato esattamente questo. Ora ogni tentativo prende il suo posto nel conteggio in un unico passo atomico, prima di qualsiasi verifica, e lo restituisce solo se era giusto.

**Se falliscono, i limiti chiudono.** Se l'archivio che li conta non risponde, l'accesso viene rifiutato e lo dice, invece di lasciar passare tutto. L'unica eccezione è un limite largo di 600 richieste al minuto per indirizzo sul resto dell'host, discovery e chiavi comprese: lì non c'è nulla da indovinare, quindi un guasto del contatore non deve bloccarlo.

**Un blocco non può essere usato contro il proprietario.** Bloccare un account dopo qualche password sbagliata permette a chiunque di tenerne fuori il proprietario: cinque tentativi sbagliati ogni quarto d'ora, per sempre. Per questo un browser che ha completato un accesso a un account porta un cookie per 90 giorni e conserva una piccola quota propria mentre l'account è bloccato per tutti gli altri. Chi tira a indovinare può rallentare l'account per gli estranei, non per il suo proprietario.

**IPv6 viene contato per il suo /64**, perché una connessione può scegliere qualsiasi indirizzo di origine al suo interno.

L'endpoint dei token conta le richieste di un'applicazione solo dopo che il client si è autenticato, altrimenti chiunque potrebbe esaurire la quota di qualcun altro. Un browser o un'app mobile non ha un secret, quindi lì la quota è contata per applicazione e indirizzo: un estraneo che la consuma consuma solo la propria.

## I moduli dimostrano da dove arrivano, e così il logout

La schermata di consenso e la pagina dell'account si affidavano alle regole SameSite del browser, un default con una lunga storia di eccezioni, per impedire ad altri siti di inviare dati verso di loro. Ora ogni modulo lì porta un token legato alla sessione e deve essere inviato da eauth.me stesso.

Il logout avveniva con qualsiasi `GET /logout`, quindi qualsiasi pagina poteva disconnettere chiunque con un link: il primo passo per convincere qualcuno ad accedere di nuovo su una pagina scelta da chi attacca. Ora il logout segue l'RP-Initiated Logout di OpenID Connect ed è elencato nella discovery come `end_session_endpoint`. La sessione termina quando l'applicazione invia un `id_token_hint` che nomina la persona connessa ed è stato emesso durante questa sessione. Senza, EAuth chiede prima.

## Nessuna applicazione riceve un indirizzo non confermato

`email_verified` era false in ogni ID token emesso da EAuth prima di questo rilascio. Vero, perché nulla aveva mai verificato un indirizzo, e inutile. Ora la registrazione invia un link che funziona una volta, per 24 ore. Aprirlo conferma l'indirizzo.

La parte più severa è nuova dal 3 ottobre: nessuna applicazione riceve un account il cui indirizzo non sia confermato. Chi si registra viene fermato sulla via del ritorno all'applicazione da una pagina che invia un nuovo link, e il link riporta al punto in cui l'accesso si era fermato. Con `prompt=none` l'applicazione riceve invece `interaction_required`. Così, in un token che proviene da un accesso, `email_verified` è sempre true. La nostra console è tenuta alla stessa regola.

Un indirizzo non confermato è una stringa che chiunque potrebbe digitare, e un estraneo che accedesse con quella stringa riceverebbe gli inviti destinati a quella casella. Valgono come conferma anche un reset della password, il single sign-on tramite il provider di identità di un'organizzazione o un'importazione marcata come confermata; a ogni altro account importato la conferma viene chiesta al primo accesso. Il costo è un passaggio in più per chi prova un'applicazione per la prima volta. Penso che ne valga la pena.

Lo stesso meccanismo porta il reset della password, che finora significava scriverci. La richiesta risponde allo stesso modo che l'account esista o no, e un link funziona una volta, per un'ora, e solo il più recente. Aprirlo mostra un modulo e non consuma nulla, perché anche gli scanner della posta aprono i link. Impostare la nuova password disconnette ogni dispositivo e ogni applicazione.

I link sono 256 bit casuali, salvati solo come digest, come ogni altra credenziale qui. Una copia del database non può confermare né reimpostare nulla.

## Cosa non è fatto

Le passkey funzionano accanto alle password, e un'organizzazione può far accedere i propri membri tramite il proprio provider di identità con SAML. Cosa manca ancora: le e-mail che EAuth invia sono solo in inglese. Non c'è stato nessun audit di sicurezza indipendente; la revisione citata sopra era la nostra. La disponibilità misurata comparirà su status.elchi.dev quando sarà stato misurato un mese intero, non prima. L'accesso con l'e-ID svizzera è in preparazione, e non c'è ancora nulla che un'applicazione possa usare.

Chi costruisce su EAuth indica a mano una sola cosa: l'issuer, `https://eauth.me`. Tutto il resto arriva dalla discovery.

## Fonti

1. [RFC 9700: Best Current Practice for OAuth 2.0 Security](https://www.rfc-editor.org/rfc/rfc9700), IETF, consultato il 2026-10-03
2. [OpenID Connect RP-Initiated Logout 1.0](https://openid.net/specs/openid-connect-rpinitiated-1_0.html), OpenID Foundation, consultato il 2026-10-03
3. [OpenID Connect Core 1.0, Standard Claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims), OpenID Foundation, consultato il 2026-10-03
4. [RFC 6238: TOTP, Time-Based One-Time Password Algorithm](https://www.rfc-editor.org/rfc/rfc6238), IETF, consultato il 2026-10-03
5. [RFC 9110: HTTP Semantics, 308 Permanent Redirect](https://www.rfc-editor.org/rfc/rfc9110.html#name-308-permanent-redirect), IETF, consultato il 2026-10-03
6. [Web Authentication: An API for accessing Public Key Credentials, Level 3](https://www.w3.org/TR/webauthn-3/), W3C, consultato il 2026-10-03
7. [Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html), OWASP, consultato il 2026-10-03
8. [Site (glossary)](https://developer.mozilla.org/en-US/docs/Glossary/Site), MDN, consultato il 2026-10-03