認証と認可の設計 — セッション・JWT・OAuth
「ログイン機能を作って」と言われたとき、認証の方式選定から始められるかどうかは設計力の分かれ目です。 セッション、JWT、OAuth——それぞれの仕組みと使いどころを理解しておかないと、セキュリティ上の事故にもつながります。
この章では、認証と認可の違いから、主要な認証方式の比較までを整理します。
学習者「認証」と「認可」って同じじゃないの？セッションとJWT、どっちを選べばいいの…？
認証と認可の違い
この2つは混同されがちですが、まったく別の概念です。
| 概念 | 質問 | 例 |
|---|---|---|
| 認証（Authentication） | 「あなたは誰？」 | ログイン、本人確認 |
| 認可（Authorization） | 「あなたは何ができる？」 | 管理者のみ削除可能、一般ユーザーは閲覧のみ |
認証が通っても、認可されていない操作はブロックする必要があります。
主要な認証方式の比較
| 方式 | 状態管理 | 適するケース |
|---|---|---|
| セッション | サーバー側（メモリ/DB/Redis） | 従来型Webアプリ、SSR中心 |
| JWT | クライアント側（トークン） | SPA、モバイルアプリ、マイクロサービス |
| OAuth 2.0 | 外部サービスに委譲 | ソーシャルログイン、外部API連携 |
残りのセクションは現在執筆中です。
- セッション方式の仕組みとセキュリティ（CSRF対策）
- JWTの構造（Header.Payload.Signature）と注意点
- リフレッシュトークンの設計
- OAuth 2.0のフロー（認可コードフロー）
- ロールベースアクセス制御（RBAC）の設計
ちゃんと使うためのポイント
- 認証（誰か）と認可（何ができるか）は別の仕組みとして設計する
- JWTはステートレスだがトークン無効化が難しい。要件に応じて選定する
- セッション方式はCSRF対策が必須
- 「どの方式が正解か」ではなく、要件（SPA？SSR？モバイル？）で選ぶ
次の章では、認証後のアプリケーション内部の状態管理の設計を見ていきます。