【図解で比較】Cookie vs セッション — Web認証の仕組みを徹底解説

いい疑問だね。実はHTTPっていう通信の仕組みは「ステートレス」といって、1回のやり取りごとに相手のことを忘れちゃうんだ。だからログイン状態を覚えておくために「Cookie」や「セッション」という仕組みが必要になるんだよ

Cookieはブラウザ側に保存される小さなテキストデータだよ。サーバーが「この情報を覚えておいて」とブラウザに渡して、次のリクエストのときにブラウザが自動的にその情報をサーバーに送り返す仕組みなんだ。ショッピングサイトのカート情報や言語設定なんかもCookieで管理されていることが多いね

セッションはユーザーの情報をサーバー側に保存する仕組みだよ。サーバーが「セッションID」という短い識別子だけをCookieに入れてブラウザに渡すんだ。ブラウザはそのIDだけを送り返して、サーバーがIDをもとに「ああ、この人はさっきログインした山田さんだな」とデータを引き出す流れだね

大きく分けて2種類あるよ。ブラウザを閉じると消える「セッションCookie」と、有効期限を指定して長期間残る「永続Cookie」だね。ログイン状態を1週間保持する「次回から自動ログイン」みたいな機能は永続Cookieを使っていることが多いよ

まさにそこが重要なポイントだね。まずCookieには「HttpOnly」という属性があって、これをつけるとJavaScriptからCookieを読めなくなるからXSS攻撃への対策になる。「Secure」属性をつけるとHTTPS通信のときだけCookieが送られるようになるよ。さらに「SameSite」属性で、別のサイトからのリクエストにCookieを付けないよう制限できるんだ

JWTはJSON Web Tokenの略で、ユーザー情報をトークンという文字列に暗号化して埋め込む方式だよ。セッションと違ってサーバー側にデータを保存しなくていいのが大きな特徴だね。トークン自体に「誰がいつログインした」という情報が入っていて、署名で改ざんを検知できる仕組みなんだ。マイクロサービスやSPAのようなモダンなアーキテクチャではJWTが主流になってきているよ

その通り。OAuthでは認可コードを受け取ったあと、サーバーがアクセストークンを取得して、それをもとにセッションやJWTを発行するんだ。つまりOAuthはログインの入口の仕組みで、ログイン状態の維持にはやっぱりCookieやトークンが必要になるんだよ

セッション固定攻撃は、攻撃者が用意したセッションIDをターゲットに使わせて、ログイン後にそのIDでなりすます手口だよ。対策はログイン成功時にセッションIDを必ず再発行すること。CSRFはCross-Site Request Forgeryの略で、ログイン中のユーザーに意図しないリクエストを送らせる攻撃だね。SameSite属性やCSRFトークンで防ぐのが定番だよ

いいところに気づいたね。JWTは有効期限を短くして、たとえば15分で切れるアクセストークンと、数日間有効なリフレッシュトークンを組み合わせるのが一般的だよ。アクセストークンが漏れても被害を最小限に抑えられるし、リフレッシュトークンはHttpOnlyのCookieに保存してJavaScriptから触れないようにする。万が一のためにサーバー側でリフレッシュトークンを無効化できる仕組みも入れておくと安心だね