Das Auth-Token bleibt im Cookie
Login, Register, Logout und der aktuelle User liegen unter /api. Das Token ist httpOnly auth_token. Es landet nicht in localStorage und nicht im JSON-Body.
Die öffentliche Auth-API sind vier Routen: /api/login, /api/register, /api/logout und /api/user. Sanctum schreibt die Session in ein httpOnly-Cookie namens auth_token. Login gibt kein Token-Feld mehr zurück. Nichts auf dem Client schreibt ein Token nach localStorage.
Kann ein Skript auf dem Origin die Session lesen, schickt XSS sie weg. Ein httpOnly-Cookie ist aus JavaScript nicht erreichbar. Dieselbe Injection kann auth_token nicht kopieren. Logout löscht Server-Token und Cookie, ein kopiertes Cookie funktioniert also sofort nicht mehr.
CSRF bei jedem Write
Unsichere Methoden brauchen das CSRF-Cookie und den passenden Header. Das Frontend holt das Cookie einmal und sendet den Header bei jedem Write. Ein fehlender oder veralteter Header liefert 419, keinen Validierungsfehler, der wie ein falsches Passwort aussieht.
Admin-Routen liegen hinter derselben Cookie-Session. Eine abgelaufene Session leitet zum Login statt auf eine kaputte Seite. Die Login-Route rotiert die Session-ID.
Was die Tests halten
Vier Fälle regressierten früher. Kein Token im Login-JSON. Das httpOnly-Flag an auth_token gesetzt. Ein Write ohne CSRF-Header abgelehnt. /api/user liefert nach Logout 401.
Die Regel ist kurz genug zum Halten. Tokens leben in Cookies. JSON-Bodies tragen User-Felder, keine Secrets. Braucht ein neuer Screen den aktuellen User, ruft er /api/user mit Credentials. Er erfindet keinen zweiten Store.