---
title: "EAuth passe sur eauth.me, et chaque porte est comptée"
summary: "EAuth a son domaine, eauth.me, et auth.elchi.dev y redirige. Avec lui : des limites sur chaque connexion, des formulaires vérifiés, des adresses confirmées."
author: "Samuel Krauss"
author_title: "Founder"
publisher: "Elchi Studios"
published: 2026-10-03
updated: 2026-10-09
url: https://elchi.dev/fr/journal/eauth-passe-sur-eauth-me-et-chaque-porte-est-comptee
language: fr
translation_of: https://elchi.dev/en/journal/eauth-moves-to-eauth-me
tags: ["eauth","security"]
words: 1614
---

# EAuth passe sur eauth.me, et chaque porte est comptée

*Par Samuel Krauss, Founder. Publié le 3 octobre 2026.*

> EAuth a son domaine, eauth.me, et auth.elchi.dev y redirige. Avec lui : des limites sur chaque connexion, des formulaires vérifiés, des adresses confirmées.

EAuth a désormais un domaine à lui : **eauth.me**. L'issuer est `https://eauth.me`, et la connexion comme la page du compte vivent sur le domaine racine. Depuis le 3 octobre 2026, auth.elchi.dev répond à chaque requête par une redirection permanente `308` vers le même chemin sur eauth.me. Ce déménagement a été l'occasion de revoir tout ce qu'une personne touche en entrant : chaque porte est maintenant comptée, les formulaires prouvent leur provenance, la déconnexion exige une preuve, et aucune application ne reçoit une adresse que personne n'a confirmée.

## Pourquoi EAuth a déménagé

EAuth a commencé comme la connexion de notre propre console et de notre tableau de bord, et elchi.dev était donc le domaine évident. Une adresse placée sous le site d'une agence dit « une fonctionnalité de ce site ». EAuth est un produit sur lequel d'autres développeurs peuvent construire, et il reçoit une adresse qui le dit.

Il y a aussi une raison de sécurité. Les navigateurs envoient les cookies par site, et un site, c'est le domaine enregistrable, pas le nom d'hôte. Sur auth.elchi.dev, chaque page de chaque sous-domaine d'elchi.dev appartenait au même site que la page qui détient la session de connexion de tout le monde. Aucune ne s'est mal comportée, mais c'est un cercle de confiance plus large que ce qu'un service de connexion devrait avoir.

Et il fallait le faire avant les passkeys et le single sign-on. Une passkey appartient à un seul domaine, et le navigateur ne la propose nulle part ailleurs ; le fournisseur d'identité d'une organisation se configure une fois avec l'entity ID et l'adresse de réponse d'EAuth. Les deux vivent sur eauth.me dès le départ, et aucun n'aura à être refait à cause d'une adresse.

Ce que cela coûte : une connexion de plus pour tout le monde, puisque les sessions appartenaient à l'ancien hôte. Et chaque intégration doit nommer le nouvel issuer. Un client compare l'issuer comme une chaîne, les tokens d'eauth.me indiquent `https://eauth.me`, et une bibliothèque qui le vérifie, comme elle le doit, les refuse tant que son réglage ne correspond pas.

## Pas de chevauchement, et pourquoi il n'en fallait pas

Un issuer modifié casse les intégrations, et nos conditions promettent un préavis avant un tel changement. Le plan était de garder auth.elchi.dev comme issuer complet pendant 90 jours. Nous n'en avons pas eu besoin : le jour du déménagement, chaque application enregistrée auprès d'EAuth appartenait à Elchi Studios, et personne hors de l'entreprise n'avait de compte. L'ancienne adresse redirige donc dès le jour du déménagement, et les conditions le disent dans leur version 1.7, clause 2.4.

La redirection est un `308` plutôt qu'un `301` : une requête de token envoyée à l'ancienne adresse reste un `POST` et arrive intacte. Les tokens qu'elle obtient nomment `https://eauth.me`. Pour notre propre console et notre tableau de bord, il a suffi d'un réglage, puisque chaque interface lit l'issuer dans la même valeur.

Je l'ai fait maintenant parce que maintenant, cela ne coûtait pas cher. Avec quelques centaines d'intégrations externes, ce serait un projet de migration avec un délai de préavis.

## Chaque porte est comptée

Jusqu'à cette version, l'API derrière elchi.dev avait des limites de débit, mais pas les pages où l'on tape un mot de passe. Le calcul qui a rendu la chose urgente : un second facteur est un code à six chiffres, et à tout moment, trois codes sont acceptés, parce que les horloges dérivent. Avec le mot de passe, un script dispose de cinq minutes pour le code et, sans limite, de milliers d'essais. Ce n'est pas un second facteur, c'est un délai.

Désormais, chaque endroit qui reçoit un identifiant compte deux fois : par l'adresse d'où vient la requête, et par le compte qu'elle nomme.

| Porte | Limite |
|---|---|
| Tentatives de connexion depuis une adresse, toute méthode | 30 par minute |
| Mauvais mots de passe, un compte depuis une adresse | 5 en 15 minutes |
| Mauvais mots de passe, un compte depuis n'importe où | 20 en 15 minutes |
| Connexions échouées depuis une adresse | 50 par heure |
| Mauvais codes de second facteur, un compte | 5 en 15 minutes, 20 par jour |
| Nouveaux comptes depuis une adresse | 10 par heure |
| `/authorize`, par adresse | 60 par minute |
| `/token`, par application | 120 par minute par défaut, jusqu'à 600 dans la console |

Avec vingt mauvais codes par jour, quelqu'un qui a le mot de passe et rien d'autre a besoin en moyenne d'environ 45 ans pour deviner le code.

Quatre détails comptent plus que les chiffres.

**Chaque tentative est comptée avant d'être vérifiée.** Le verrou évident vérifie le verrou, puis le mot de passe, et compte un échec après coup. Des requêtes envoyées au même instant passent toutes la première étape : un script qui tirait cent essais d'un coup obtenait cent essais. Une revue de la première version a trouvé exactement cela. Désormais, chaque tentative prend sa place dans le compteur en une seule étape atomique, avant toute vérification, et ne la récupère que si elle était juste.

**Les limites échouent en position fermée.** Si le stockage qui les compte ne répond pas, la connexion refuse et le dit, au lieu de tout laisser passer. La seule exception est une limite large de 600 requêtes par minute et par adresse sur le reste de l'hôte, discovery et clés compris : il n'y a rien à deviner là, et une panne du compteur ne devrait pas le mettre hors service.

**Un blocage ne peut pas être retourné contre le propriétaire.** Bloquer un compte après quelques mauvais mots de passe permet à n'importe qui d'en tenir le propriétaire à l'écart : cinq mauvais essais tous les quarts d'heure, indéfiniment. Un navigateur qui a mené à bien une connexion à un compte porte donc un cookie pendant 90 jours et garde un petit quota à lui pendant que le compte est bloqué pour tous les autres. Celui qui devine peut ralentir le compte pour des inconnus, pas pour son propriétaire.

**IPv6 est compté par /64**, parce qu'une connexion peut choisir n'importe quelle adresse source dans ce bloc.

Le endpoint de token ne compte les requêtes d'une application qu'après l'authentification du client, sinon n'importe qui pourrait épuiser le quota d'un autre. Un navigateur ou une app mobile n'a pas de secret : là, le quota est compté par application et par adresse, et un inconnu qui l'épuise n'épuise que le sien.

## Les formulaires prouvent leur provenance, la déconnexion aussi

L'écran de consentement et la page du compte s'appuyaient sur les règles SameSite du navigateur, un comportement par défaut qui a son lot d'exceptions, pour empêcher d'autres sites d'y poster. Chaque formulaire porte maintenant un token lié à la session et doit être posté depuis eauth.me lui-même.

La déconnexion se faisait sur n'importe quel `GET /logout` : n'importe quelle page pouvait déconnecter n'importe qui avec un lien, première étape pour amener quelqu'un à se reconnecter sur une page de son choix. La déconnexion suit maintenant OpenID Connect RP-Initiated Logout et figure dans la discovery sous `end_session_endpoint`. La session prend fin quand l'application envoie un `id_token_hint` qui nomme la personne connectée et a été émis pendant cette session. Sans lui, EAuth demande d'abord.

## Aucune application ne reçoit d'adresse non confirmée

`email_verified` valait false dans chaque ID token émis par EAuth avant cette version. C'était vrai, puisque rien n'avait jamais vérifié une adresse, et inutile. L'inscription envoie maintenant un lien qui fonctionne une fois, pendant 24 heures. L'ouvrir confirme l'adresse.

La partie plus stricte est nouvelle depuis le 3 octobre : aucune application ne reçoit de compte dont l'adresse n'est pas confirmée. Une personne qui s'inscrit est arrêtée sur le chemin du retour vers l'application par une page qui envoie un nouveau lien, et le lien ramène là où la connexion s'était arrêtée. Avec `prompt=none`, l'application reçoit `interaction_required` à la place. Dans un token issu d'une connexion, `email_verified` vaut donc toujours true. Notre propre console est soumise à la même règle.

Une adresse non confirmée est une chaîne que n'importe qui pourrait taper, et un inconnu connecté sous cette adresse recevrait les invitations destinées à cette boîte mail. Une réinitialisation de mot de passe, un single sign-on via le fournisseur d'identité d'une organisation ou un import marqué comme confirmé comptent aussi ; tout autre compte importé est sollicité à sa première connexion. Le coût, c'est une étape de plus pour quelqu'un qui essaie une application pour la première fois. Je pense que cela en vaut la peine.

Le même mécanisme apporte la réinitialisation du mot de passe, qui jusqu'ici passait par un message à notre adresse. La demande donne la même réponse, que le compte existe ou non, et un lien fonctionne une fois, pendant une heure, et seulement le plus récent. L'ouvrir affiche un formulaire et ne consomme rien, parce que les scanners de mails ouvrent aussi les liens. Définir le nouveau mot de passe déconnecte chaque appareil et chaque application.

Les liens font 256 bits aléatoires et ne sont stockés que sous forme de condensés, comme tous les autres identifiants ici. Une copie de la base de données ne permet de confirmer ni de réinitialiser quoi que ce soit.

## Ce qui n'est pas fait

Les passkeys fonctionnent à côté des mots de passe, et une organisation peut faire connecter ses membres par son propre fournisseur d'identité avec SAML. Ce qui manque encore : les mails qu'envoie EAuth ne sont qu'en anglais. Il n'y a pas eu d'audit de sécurité indépendant ; la revue évoquée plus haut était la nôtre. La disponibilité mesurée sera publiée sur status.elchi.dev une fois qu'un mois complet aura été mesuré, pas avant. La connexion avec l'e-ID suisse est en préparation, et rien n'est encore utilisable par une application.

Quiconque construit sur EAuth ne renseigne qu'une chose à la main : l'issuer, `https://eauth.me`. Tout le reste vient de la discovery.

## Sources

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