Web開発ではさまざまな認証方式がでてきますが、まとめておかないとそれぞれの方式のイメージやメリデメなどがわからないため、自分のわかっている範囲でまとめをしておこうと思います。

セッション・クッキー方式

サーバーがセッションIDを発行し、クライアントのCookieに保存する従来型の認証方式。
サーバー側でセッション情報を管理するステートフルな仕組みで、実装がシンプルで多くのWebフレームワークに標準搭載されています。ブラウザベースのWebアプリケーションでよく使われています。

※セッションの情報自体はDB以外にもメモリキャッシュなどいろいろ考えられます。

メリット：

実装の容易さ
- 多くのWebフレームワークで標準的にサポート
- 従来からの確立された認証方式で実装例が豊富
- セッション管理をサーバー側で一元的に行える
セキュリティ面
- セッションIDのみをクライアントに保持し、機密情報はサーバーで管理
- セッションタイムアウトの設定が容易
- セッション無効化（ログアウト）が確実に行える

デメリット：

スケーラビリティの課題
- サーバーでセッション情報を保持するため、メモリ消費が増大
- 複数サーバーでの運用時、セッション情報の同期が必要
- 水平スケーリングが複雑になる
- RestfulAPIとの親和性の低さ
ステートフル性による制約
- サーバー側で状態を保持する必要がある
- サーバーダウン時にセッション情報が失われる可能性
API利用での制約
- Cookieベースの制限
- クロスオリジンでの制約

トークン(Opaque Token)方式

ランダムな文字列をトークンとして発行し、サーバーのデータベースでトークンとユーザー情報を紐付けて管理する方式です。

トークン自体には意味がなく、検証には必ずデータベースへの問い合わせが必要となります。即座に無効化できるためセキュリティ性が高く、Refresh Tokenとしてよく使われています。

メリット：

APIとの親和性
- クロスプラットフォームでの実装が容易
- モバイルアプリなどでも扱いやすい
セキュリティ管理
- トークンの即時無効化が可能
- トークンの有効期限管理が容易
- アクティブなセッション（トークン）の把握が容易
実装の柔軟性
- トークンに紐づく情報の管理が自由

デメリット：

パフォーマンス
- 毎リクエストでDBアクセスが必要
- トークン検証のオーバーヘッド
- DBへの負荷が高い
スケーラビリティ
- トークン情報のDB同期が必要

使い分けのポイント：

アプリケーションの性質
- Webアプリケーション中心 → セッション認証
- API中心のシステム → トークン認証
スケール要件
- 単一サーバー/小規模 → セッション認証
- 大規模/分散システム → トークン認証
クライアントの多様性
- ブラウザのみ → セッション認証
- 多様なクライアント → トークン認証

JWT

ユーザー情報をJSON形式でエンコードし、デジタル署名を付与した自己完結型のトークン。
サーバーはデータベース不要で署名検証のみで認証できるステートレスな仕組み。マイクロサービスやAPI認証に最適ですが、有効期限まで無効化できない課題があります。

JWTとは？

JWTは「JSON Web Token」の略です。これは「デジタル署名付きのIDカード」のようなもの

仕組みを例え話で説明すると...

お店（ウェブサイト）に行く時のことを想像してください：

ログイン（身分証明）

あなた：「こんにちは！私はAさんです。パスワードは1234です」
お店：「確認しました。このIDカード（JWT）を渡します」

IDカード（JWT）の中身

- 名前：Aさん
- 会員番号：12345
- 有効期限：2024年3月1日まで
- お店の印鑑（デジタル署名）

お店を利用する時（APIにアクセスする時）

あなた：「商品を見たいです。はい、IDカードです」
お店：「IDカードを確認しました。どうぞご覧ください」

メリット

完全なステートレス
- サーバー側でセッション情報を保持する必要がない
- データベースへのクエリが不要
- サーバーのメモリを消費しない
セキュリティ管理
- どのサーバーでも独立してトークン検証可能
クロスドメイン、クロスオリジリン対応
- CORSに強い
- 複数のサブドメイン・サービス間で共有可能
- マイクロサービスアーキテクチャに最適
- モバイルに最適
改ざん検知が可能
- デジタル署名により改ざんを検出
- HMAC、RSA、ECDSAなど複数のアルゴリズム対応
- 信頼性の高い検証メカニズム

デメリット：

トークンの無効化が困難
- 有効期限まで強制的に無効化できない
- ログアウトしてもトークンは有効なまま
トークンサイズの肥大化
- 200文字〜1000文字

Opaque tokenとの違い

トークン生成と検証
- JWT: トークン自体に情報が含まれ、秘密鍵で検証可能
- Opequeトークン: ランダムな文字列で、必ずDBで検証が必要
サーバーサイドの状態管理
- JWT: 基本的にステートレス（DB検証不要）
- Opaqueトークン: トークンとユーザー情報をDBで管理
トークンの無効化
- JWT: 有効期限までサーバーで無効化が難しい
- Opaqueトークン: DBから削除することで即時無効化可能
セキュリティ特性
- JWT: 改ざん検知が可能
- Opaqueトークン: 予測不可能な文字列であることが重要

Oauth

外部サービス（Google、GitHubなど）のアカウントを使って認証・認可を行うオープンな標準プロトコルです。

ユーザーはパスワードを共有せず、限定的な権限のみをアプリケーションに委譲できます。
ソーシャルログインやAPI連携に広く使われています。

OAuthのメリット:

セキュリティ
- パスワードを直接アプリケーションに渡す必要がない
- 既存のアカウント（Google、Facebookなど）でログイン可能
- 複数サービスで同じアカウントが使える（シングルサインオン）
- パスワードを覚える必要が少ない
開発・運用
- 認証基盤の実装・運用コストを削減できる
- 標準化されたプロトコルで相互運用性が高い
- セキュリティのベストプラクティスが組み込まれている

OAuthのデメリット:

複雑性
- 実装が比較的複雑
- フローの理解・管理が必要
依存性
- 認証プロバイダーに依存
- プロバイダーの障害時にサービスに影響
- プロバイダーの仕様変更への対応が必要

まとめ

それぞれの認証方式を比較した表を作成します。

認証方式	特徴	メリット	デメリット	適した用途
セッション・クッキー	・サーバーサイドでセッション情報を保持・クライアントにはセッションIDをクッキーとして保存・ステートフル（状態を持つ）な認証方式	・実装が比較的シンプル・セッションの無効化が容易・多くのフレームワークで標準サポート・ブラウザの標準機能を利用	・サーバーリソースを消費・スケーリングが複雑・CSRF攻撃への対策が必要・モバイルアプリとの相性が悪い	・Webアプリケーション中心のシステム・シンプルな要件の場合
トークン	・サーバーがアクセストークンを発行・クライアントがトークンを保持・ステートレスな認証が可能	・スケーラビリティが高い・クロスドメイン対応が容易・モバイルアプリとの相性が良い・サーバー負荷が低い	・トークンの管理が必要・漏洩時のリスクが高い・通信オーバーヘッド・有効期限管理が必要	・モバイルアプリケーション・分散システム
JWT	・JSON形式の情報をエンコード・署名付きのトークン・クレームを含められる	・完全にステートレス・トークンに情報を含められる・改ざん検知が可能・標準化されている	・トークンサイズが大きい・無効化が難しい・秘密鍵の管理が重要・情報漏洩リスク	・マイクロサービス・分散システム・サービス間認証
OAuth	・認可プロトコル・サードパーティ認証・アクセス権限の委譲が可能	・標準化された安全なフロー・細かい権限制御が可能・パスワードを直接扱わない・シングルサインオン対応	・実装が複雑・外部サービスへの依存・フロー理解が必要・プロバイダーの障害影響	・外部サービス連携・ソーシャルログイン