セッションによる認証とトークンによる認証の比較
セッションによる認証とトークンによる認証の違い
- セッションによる認証とは、PHPの標準セッション機能のように、ウェブサーバでセッションIDを作り、ブラウザがリクエスト時にそのセッションIDを含めて送信する。ウェブサーバはセッションIDをもとにしてそれに紐づいたセッションデータ（ユーザ情報など）を取得する
- トークンによる認証とは、ウェブサーバでトークンを作り、（ユーザ情報などの）セッションデータを暗号化してブラウザにトークンとして送る。ブラウザはリクエスト時にそのトークンを送り返す。ウェブサーバは送り返されたトークンを復号してセッションデータを取得する
https://dev.to/thecodearcher/what-really-is-the-difference-between-session-and-token-based-authentication-2o39
セッションやトークンを受け渡しするためにクッキーを使うかHTTP Authorizationヘッダーを使う
- セッションによる認証の場合、多くのシステムではクッキーを使う。例えば、PHPの標準セッション機能では、セッションIDがクッキーに含まれ、ブラウザはリクエスト時にクッキーの値にセッションIDを含めて送信する
- トークンによる認証の場合、多くのシステムではHTTP Authorizationヘッダーを使う。ブラウザはリクエスト時にHTTP Authorizationヘッダーの値にトークンを含めて送信する。ただし、そうする代わりに、トークンをクッキーを使って送信するシステムもある
https://medium.com/@sherryhsu/session-vs-token-based-authentication-11a6c5ac45e4
セッションによる認証の問題点
前提：ここではセッション+クッキー、トークン+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対策 HttpOnlyフラグ
https://developer.mozilla.org/ja/docs/Web/HTTP/Cookies
参考
