Ein strikter Cookie und eine neue Domain
Seit EAuth eine eigene Domain hat, führte das Login in die Konsole zurück zur Login-Seite. Warum ein SameSite=Strict-Cookie das tut und was es für Sie heisst.
Der Umzug von EAuth auf eauth.me hat das Login in unsere eigene Konsole auf eine Art kaputt gemacht, die nach gar nichts aussah: Sie meldeten sich an und landeten wieder auf der Login-Seite. Wir haben das acht Tage vor dem Go-live des Umzugs gefunden und sofort behoben. Die Ursache lohnt sich aufzuschreiben, denn wer sich mit EAuth anmeldet und einen strikten Session-Cookie setzt, wird auf dasselbe stossen.
Was passiert ist
Das Login in die Konsole läuft so ab. Die Konsole schickt Sie zu EAuth, EAuth prüft Ihr Passwort und schickt Sie mit einem Code zurück an die Callback-Adresse der Konsole. Der Callback tauscht den Code ein, setzt den Session-Cookie der Konsole und leitet Sie zur eigentlichen Konsole weiter.
Der Session-Cookie der Konsole ist SameSite=Strict, der des Dashboards ebenfalls. Ein strikter Cookie wird nur bei einer Anfrage mitgeschickt, die dieselbe Site gestartet hat. Startet eine andere Site die Navigation, wird er nie mitgeschickt, nicht einmal bei einem einfachen Link. Für eine Administrationsoberfläche ist das bewusst so gewählt: Keine Seite irgendwo sonst kann Ihren Browser in der Konsole handeln lassen, während Sie angemeldet sind.
Solange EAuth auf auth.elchi.dev lag, waren EAuth und die Konsole dieselbe Site, denn ein Browser entscheidet „same site“ anhand der registrierbaren Domain, elchi.dev, nicht anhand des vollen Hostnamens. Auf eauth.me sind sie das nicht. Die Navigation zurück zum Callback startet jetzt eauth.me. Der Callback setzte den Cookie und antwortete mit einem Redirect zur Konsole, und der Browser schickte diese nächste Anfrage ohne den Cookie. Ein Redirect von unserem eigenen Server änderte nichts daran, wer die Navigation gestartet hatte. Die Konsole sah keine Session und zeigte die Login-Seite.
Was wir geändert haben
Es gibt drei übliche Antworten.
- Den Cookie auf
Laxsetzen. Ein Lax-Cookie wird bei einer Top-Level-Navigation von einer anderen Site mitgeschickt, der Redirect würde ihn also mitnehmen. Für die meisten Anwendungen ist das der richtige Standard. Für unsere Konsole und unser Dashboard wollten wir bei Strict bleiben. - Zwei Cookies verwenden, einen laxen, der nur sagt „jemand ist angemeldet“, und einen strikten für alles, was etwas ändert. Solide, aber mehr bewegliche Teile, als wir brauchten.
- Den Callback auf einer eigenen Seite enden lassen. Der Callback setzt den Cookie und antwortet mit einer kleinen Seite, die von selbst weitergeht. Eine Navigation, die diese Seite startet, hat die eigene Site der Konsole gestartet, also geht der strikte Cookie mit.
Wir haben die dritte gewählt. Die Seite hat eine Refresh-Anweisung und einen einfachen Link, kein Skript, und steht so lange auf dem Bildschirm, wie eine Anfrage dauert. Sie schickt den Browser immer nur auf einen Pfad auf dem eigenen Host der Konsole: Alles andere, was sie bekommt, wird zur Startseite, und die Prüfung dafür steht im Code, nicht im Template. Die Seite sendet keinen Referrer und wird nie gecacht.
Der Preis ist klein: Der Callback antwortet mit ein paar Zeilen HTML statt mit einem Redirect, und ein Browser, der den Refresh ignoriert, zeigt einen Link zum Anklicken. Strikte Cookies in der Konsole aufzugeben, hätte mehr gekostet, nur weniger sichtbar.
Wenn Sie auf EAuth aufbauen
Seit dem 3. Oktober 2026 leitet auth.elchi.dev nur noch auf eauth.me weiter, also liegt jede Anwendung, die sich über EAuth anmeldet, auf einer anderen Site als EAuth. Daraus folgen drei Dinge.
- Ein strikter Session-Cookie verhält sich wie unserer. Setzen Sie ihn im Callback und leiten dann weiter, kommt die nächste Anfrage ohne ihn an. Nehmen Sie entweder
Lax, oder lassen Sie den Callback auf einer Seite enden, die weiternavigiert. - Was Sie speichern, bevor Sie jemanden zu EAuth schicken, also den
stateund den PKCE-Verifier, muss bei dieser Cross-Site-Navigation zurückkommen. In einem Cookie heisst dasLax. Unser SDK hält beides im Session Storage, für den es keine solche Regel gibt: Er gehört zum Tab, und es ist derselbe Tab, der zurückkommt. - Abmelden funktioniert gleich, nur in die andere Richtung: Schicken Sie den Browser an den
end_session_endpointvon EAuth, mit dem ID-Token, das Sie haben, alsid_token_hint, dann kommt er an die Post-Logout-Adresse zurück, die Sie registriert haben. Ohne den Hint fragt EAuth die Person, bevor es sie abmeldet, und schickt sie nicht an eine Adresse weiter, die es nicht prüfen kann.
Der Session-Cookie von EAuth selbst ist genau aus dem ersten Grund Lax: Er muss ankommen, wenn eine Anwendung jemanden zum Login schickt, und diese Navigation startet immer eine andere Site. Die Formulare auf den Seiten von EAuth verlassen sich nicht allein darauf. Jedes trägt ein aus der Session abgeleitetes Token und muss von eauth.me selbst abgeschickt werden.
Quellen
- Set-Cookie header, SameSite, MDN, gelesen am
- Cookies: HTTP State Management Mechanism (draft-ietf-httpbis-rfc6265bis), IETF, gelesen am
- Site (glossary), MDN, gelesen am
- OpenID Connect RP-Initiated Logout 1.0, OpenID Foundation, gelesen am
Geschrieben von Samuel Krauss, Founder. Abgelegt unter eauth, cookies.
Übersetzt aus dem Englischen. Zum englischen Original