HTTP通信の認証には、大きく分けてトークンベースとセッションベースがあります。
両者についてまとめてみました。
セッションベース
セッションベースの認証には主にクッキーが使われます。
クッキーはセッション管理の代名詞とも言える基本的な技術となります。
クッキーはセッション管理の技術として歴史が長いです。
というのも、そもそもHTTP通信はステートレス（前回通信の状態を保持しない）な設計になっています。
昔々の静的なHTMLを表示するだけのWebページばかりの頃は、この設計で十分でした。
しかし、ECサイトなどが登場したことでステートフル（前回通信の状態を保持する）必要が出てきました。
例えば、買い物かごに商品を入れてページを遷移しても買い物かごに商品が残っている状態を目指す必要があったという感じです。
そんなときに登場したのがクッキーです。
クッキーにセッション情報を保存して、通信の都度クッキーを更新するようにしました。
クッキーはサーバー側が発行してクライアントのブラウザに保存します。
通信を行うたびに、クライアントからサーバーに対してクッキーを送信します。
サーバー側はクッキーを受け取って情報を確認し、変更の必要がある場合はクライアントに対してクッキーを更新して返信します。
クッキーはクライアントからサーバーに通信するときに自動で送信するようになっています。
とはいえ、闇雲にどのサーバーに対して全てのクッキーを送りつけるわけではありません。
クッキーはドメイン単位で管理されているため、クライアントの通信先によって送るクッキーと送らないクッキーがあります。
このようにクッキーは都度通信に用いられることもあり、4KBまでという情報量の制約があります。
ブラウザにもどんどん保存されていくため、あまり容量が大きくなってしまうとブラウザの動きが鈍くなってしまいます。
一方、サーバー側としてもクライアントの数だけクッキーを管理しなければならないため、負荷が大きいです。
クッキーの説明が長々となってしまいましたが、このようなクッキーの特性は認証と相性が良く、それまであったBasic認証やDigest認証よりも一般的に利用されるようになりました。
認証としてクッキーを使う際のメリットとしては、技術が成熟しているので実装が比較的容易であることです。
デメリットは、クッキーの偽装・改善などによってなりすましが可能となってしまうことです。
トークンベース
トークンベースの認証には、その名の通りトークンが使用されます。
トークンは、OIDCやSAMLといった認証プロトコルで使用されるIDトークン・アクセストークンなどのことを指します。
IDトークンやアクセストークンは、認証認可時にサーバーからクライアントに提供されるものです。
JWTと呼ばれる、暗号化されたJSONで記載されたフォーマットが一般的です。
トークンベースも通信の都度トークンを送信します。
ですが、セッションベースとの大きな違いはステートレスである点です。
トークンベースの場合は、サーバーから送られるトークンをクライアントはただ送り返すだけで良いようになっています。
サーバー側としては、認証の状態管理はせず送られてきたトークンの検証するだけです。
このようにトークンベースは、サーバー負荷が少なくステートレスであることが特徴になります。
また、トークンはブラウザに保存される訳ではないため、ネイティブアプリのようにブラウザを使用しないアプリケーションにも使うことができるのも大きな特徴です。
トークンはサイズが決まっていないため、肥大化しやすいデメリットがあります。
クライアントの端末に保存される点についてはクッキーと同様なので、サイズの大きいトークンとしてしまうとブラウザの動作が鈍くなる可能性があります。
セキュリティ面では、トークンはサーバーの秘密鍵によって暗号化されていますが、クライアントの情報管理次第ではトークンの漏洩などによってなりすましなどが成立してしまうので、こちらも注意が必要です。
