レスポンスは正しそうなのに Set-Cookie が失敗する理由
ログイン後に auth Cookie が消えたように見えるとき、バックエンド成功とブラウザの Cookie ポリシー拒否を切り分けるためのデバッグガイドです。
レスポンスが 200 OK を返していても、ブラウザ側で有効な認証セッションが確立されないことは普通にあります。Cookie デバッグが厄介なのは、バックエンドはログイン成功だと考えているのに、ブラウザは Cookie を静かに拒否したり、想定外のスコープに閉じ込めたりするからです。
重要なのは成功ステータスを眺め続けることではなく、まず生の Set-Cookie 行を見て、その後にヘッダーポリシーの問題、クロスオリジン配送の問題、トークン内容の問題を順番に切り分けることです。
保存動作が確認できてからトークン内容を調べる
ブラウザに Cookie が保存されるようになったのにセッションだけ失敗する場合、初めてその中身のトークンやセッションペイロードを調べる意味が出てきます。その段階では、有効期限、issuer、claim の不一致が認証失敗の理由になり得ます。
順番が重要なのは、拒否される Cookie の中に有効な JWT が入っていても、ログインフローとしては失敗しているからです。
このセクションで使うツール
Set-Cookie Header Inspector
Inspect raw Set-Cookie response headers, surface effective attributes, and flag browser policy issues such as SameSite=None without Secure.
CORS Header Checker
Check whether a browser request will pass CORS based on the request method, custom headers, credentials mode, and the response headers your API returns.
JWT Decoder
Decode and inspect JWT tokens instantly to view headers, payloads, and expiration status locally in your browser.