Un cookie strict et un nouveau domaine
Depuis qu'EAuth a son domaine, se connecter à notre console ramenait au formulaire. Pourquoi un cookie SameSite=Strict fait cela, et ce que ça change pour vous.
Le passage d'EAuth sur eauth.me a cassé la connexion à notre propre console d'une façon qui n'avait l'air de rien : vous vous connectiez, et vous retombiez sur la page de connexion. Nous l'avons découvert huit jours avant la mise en service du nouveau domaine, et corrigé dans la foulée. La cause mérite d'être notée, parce que toute personne qui se connecte avec EAuth et garde un cookie de session strict tombera sur le même problème.
Ce qui s'est passé
La connexion à la console se déroule ainsi. La console vous envoie vers EAuth, EAuth vérifie votre mot de passe et vous renvoie vers l'adresse de callback de la console avec un code. Le callback échange le code, pose le cookie de session de la console et vous envoie vers la console elle-même.
Le cookie de session de la console est en SameSite=Strict, celui du tableau de bord aussi. Un cookie strict n'est envoyé qu'avec une requête lancée par le même site. Il n'est jamais envoyé quand un autre site lance la navigation, pas même pour un simple lien. Pour une interface d'administration, c'est un choix délibéré : aucune page d'un autre site ne peut faire agir votre navigateur dans la console pendant que vous êtes connecté.
Tant qu'EAuth vivait sur auth.elchi.dev, EAuth et la console formaient le même site, parce qu'un navigateur juge du « même site » d'après le domaine enregistrable, elchi.dev, et non d'après le nom d'hôte complet. Sur eauth.me, ce n'est plus le cas. La navigation de retour vers le callback est désormais lancée par eauth.me. Le callback posait le cookie et répondait par une redirection vers la console, et le navigateur envoyait la requête suivante sans le cookie. Une redirection depuis notre propre serveur ne changeait rien au site qui avait lancé la navigation. La console ne voyait aucune session et affichait la page de connexion.
Ce que nous avons changé
Il existe trois réponses habituelles.
- Passer le cookie en
Lax. Un cookie lax accompagne une navigation de premier niveau venue d'un autre site, la redirection l'emporterait donc. Pour la plupart des applications, c'est le bon réglage par défaut. Pour notre console et notre tableau de bord, nous voulions rester en strict. - Utiliser deux cookies, un lax qui dit seulement « quelqu'un est connecté » et un strict pour tout ce qui modifie quelque chose. Solide, mais avec plus de pièces mobiles qu'il ne nous en fallait.
- Terminer le callback sur une page à nous. Le callback pose le cookie et répond par une petite page qui poursuit d'elle-même la navigation. Une navigation lancée par cette page est lancée par le site de la console, donc le cookie strict part avec elle.
Nous avons choisi la troisième. La page contient une instruction de rafraîchissement et un simple lien, sans script, et reste à l'écran le temps d'une requête. Elle n'envoie jamais le navigateur ailleurs que vers un chemin sur l'hôte de la console : toute autre destination qu'on lui donne devient la page d'accueil, et ce contrôle est dans le code plutôt que laissé au template. La page n'envoie pas de referrer et n'est jamais mise en cache.
Le coût est faible : le callback répond par quelques lignes de HTML au lieu d'une redirection, et un navigateur qui ignore le rafraîchissement affiche un lien sur lequel cliquer. Renoncer aux cookies stricts sur la console aurait coûté plus, simplement de façon moins visible.
Si vous construisez sur EAuth
Depuis le 3 octobre 2026, auth.elchi.dev ne fait plus que rediriger vers eauth.me, donc chaque application qui se connecte avec EAuth est sur un autre site qu'EAuth. Trois conséquences.
- Un cookie de session strict se comporte comme le nôtre. Posez-le dans le callback puis redirigez, et la requête suivante arrive sans lui. Utilisez
Lax, ou terminez le callback sur une page qui poursuit la navigation. - Ce que vous stockez avant d'envoyer quelqu'un vers EAuth, le
stateet le verifier PKCE, doit revenir lors de cette navigation intersites. Dans un cookie, cela veut direLax. Notre SDK les garde dans le session storage, qui n'a pas cette règle : il appartient à l'onglet, et c'est le même onglet qui revient. - La déconnexion fonctionne de la même façon dans l'autre sens : envoyez le navigateur vers le
end_session_endpointd'EAuth avec l'ID token que vous détenez commeid_token_hint, et il revient à l'adresse de post-déconnexion que vous avez enregistrée. Sans ce hint, EAuth demande confirmation à la personne avant de la déconnecter, et ne la renvoie pas vers une adresse qu'il ne peut pas vérifier.
Le cookie de session d'EAuth lui-même est en Lax, précisément pour la première raison : il doit arriver quand une application envoie quelqu'un se connecter, et cette navigation est toujours lancée par un autre site. Les formulaires des pages d'EAuth ne comptent pas uniquement là-dessus. Chacun porte un token dérivé de la session et doit être envoyé depuis eauth.me lui-même.
Sources
- Set-Cookie header, SameSite, MDN, consulté le
- Cookies: HTTP State Management Mechanism (draft-ietf-httpbis-rfc6265bis), IETF, consulté le
- Site (glossary), MDN, consulté le
- OpenID Connect RP-Initiated Logout 1.0, OpenID Foundation, consulté le
Écrit par Samuel Krauss, Founder. Classé sous eauth, cookies.
Traduit de l’anglais. Lire l’original anglais