hariri.ch
Prenez contact

Debug ~1 min de lecture

Pourquoi un login “réussi” ne garde pas la session

Le login renvoie 200, puis l’appel suivant arrive “déconnecté” ? Ce n’est pas toujours un bug d’authentication backend.

Diagramme en trois colonnes. Colonne 1 : “Ce qui casse” avec les étapes “POST /login”, “200 + Set-Cookie”, “GET /me”, “Pas de cookie”, verdict échec. Colonne 2 : “Fausse piste” avec “Session backend”, “Middleware auth”, “JWT ou DB ?”, verdict échec. Colonne 3 : “Vraie cause” avec “Vérifier Set-Cookie”, “Domain correspond ?”, “SameSite correct ?”, “Cookie renvoyé”, verdict succès.
Le schéma montre qu’un login peut réussir alors que la session échoue parce que le navigateur refuse ou n’envoie pas le cookie selon Domain ou SameSite.

Un login peut répondre 200 et pourtant ne pas établir de session utilisable. Le symptôme classique est simple : l’appel de login réussit, puis la requête suivante arrive sans cookie de session.

Le mauvais réflexe est d’accuser immédiatement l’authentication backend. Il faut d’abord vérifier ce que fait le navigateur avec le Set-Cookie. Un cookie peut être émis correctement par le serveur mais ne pas être stocké, ou ne pas être renvoyé ensuite, à cause de ses attributs.

Exemple courant : un frontend sur app.example.com appelle une API sur api.example.com. Si le cookie est émis avec Domain=admin.example.com, il ne sera pas envoyé à l’API. Autre cas fréquent : un flux cross-site avec SameSite=Lax alors que le navigateur exige SameSite=None; Secure.

Avant de corriger le code d’authentication, il faut donc valider les attributs du cookie selon le trajet réel entre navigateur, frontend et API.

Publié par :

Dans le même esprit

À lire ensuite