セッションによる認証とトークンによる認証の比較

セッションによる認証とトークンによる認証の違い

  • セッションによる認証とは、PHPの標準セッション機能のように、ウェブサーバでセッションIDを作り、ブラウザがリクエスト時にそのセッションIDを含めて送信する。ウェブサーバはセッションIDをもとにしてそれに紐づいたセッションデータ（ユーザ情報など）を取得する
  • トークンによる認証とは、ウェブサーバでトークンを作り、（ユーザ情報などの）セッションデータを暗号化してブラウザにトークンとして送る。ブラウザはリクエスト時にそのトークンを送り返す。ウェブサーバは送り返されたトークンを復号してセッションデータを取得する

セッションやトークンを受け渡しするためにクッキーを使うかHTTP Authorizationヘッダーを使う

  • セッションによる認証の場合、多くのシステムではクッキーを使う。例えば、PHPの標準セッション機能では、セッションIDがクッキーに含まれ、ブラウザはリクエスト時にクッキーの値にセッションIDを含めて送信する
  • トークンによる認証の場合、多くのシステムではHTTP Authorizationヘッダーを使う。ブラウザはリクエスト時にHTTP Authorizationヘッダーの値にトークンを含めて送信する。ただし、そうする代わりに、トークンをクッキーを使って送信するシステムもある

セッションによる認証の問題点

スケールしづらい

  • セッションIDとユーザの紐づけをファイルに保存するので、複数台のウェブサーバで1つのサイトを構成する場合、ウェブサーバごとにバラバラのセッションになってしまう
  • したがって、memcachedなどで共有DB（ストレージ）を作って、すべてのウェブサーバはセッションをそこに保存するようにしないといけない

CSRF攻撃に弱い

  • CSRF対策のないウェブサイトの場合、悪意のあるウェブサイトを訪れてリンクを踏まされると、クッキーに含まれるセッションIDは自動的に送信されるので、ユーザが意図しないリクエストを実行してしまう

ユーザがクッキーを偽造する危険性がある

  • ユーザが他のユーザのセッションIDを知ることができれば、クッキーにあるセッションIDを偽造して、そのユーザになりすますことができる

https://www.codementor.io/byjg/using-json-web-token-jwt-as-a-php-session-axeuqbg1m

トークンによる認証の問題点

トークンの保存とリクエスト時の送信

  • ウェブサーバが発行したトークンをブラウザに保存し、リクエスト時にトークンを送信しないといけない
  • 保存場所はクッキーかHTML5 ウェブストレージ（Local Storage)
  • ウェブストレージにトークンを保存する場合、

トークンは肥大化する

  • セッションによる認証の場合はリクエスト時に送信されるのはセッションIDだけで済むが、トークンによる認証の場合はユーザ情報など様々な情報がトークンに含まれることになり、リクエストデータが大きくなる

トークンをLocal Storageに保存するかクッキーに保存するか

Local Storageに保存するメリットとデメリット

  • 保存容量に余裕があり、トークン肥大化に対応できる
  • CSRFを避けられる
  • XSSでトークンが漏洩するとセッションハイジャックされる
  • リクエスト時にJavaScriptを使ってHTTPヘッダーにトークンを含める処理が必要になる
  • ブラウザを閉じるとLocal Storage上のデータは消える

その他の検討事項

クッキー使用時のCSRF対策 HttpOnlフラグ

https://developer.mozilla.org/ja/docs/Web/HTTP/Cookies

参考

トップ   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS