なんとなくだった認証まわりのことをしっかり理解しなければいけない時が来たのでちゃんと調べてみたので自分用にまとめてみました。
まずは基本的なところからから。
Tokenとはなんなのか？
結論: 認証・認可の証明
Token認証と言っておきながら、Tokenは主に認可に使用されます。
認証と認可
-
認証（Authentication）
「誰であるか」を確認する仕組み。
例：ユーザー名＋パスワード、OAuthログインなど。 -
認可（Authorization）
「何をして良いか」を決める仕組み。
認証後に権限を判定し、利用できる機能を制御します。
ホテルに例えると
-
サーバー → ホテルそのもの
ホテルという建物や設備全体に相当します。宿泊者はホテル（サーバー）が提供する部屋やサービスを利用します。
受付（セッション管理）やカードキー（トークン）も、このホテルの仕組みの一部として機能します。 -
セッション → ホテルの「受付」
サーバー側（受付）が宿泊者の情報を一括管理します。
宿泊者はチェックイン時に本人確認を行い、以後は受付が滞在情報を保持します。
状態管理も行うため、ルームサービスの注文履歴、問い合わせ内容、現在の宿泊日数、清掃依頼の有無なども記録されます。 -
トークン → 「カードキー」や「朝食券」
宿泊者が持ち歩く権利を証明するもの。提示すれば特定のサービスを利用できます。- カードキー：部屋の入室やエレベーター利用
-
朝食券：朝食会場の入場許可
ただし盗難や紛失時には、第三者による不正利用が可能です。
トークンの種類と役割
-
アクセストークン（AT）
APIアクセスの利用許可証（短期有効）。 -
リフレッシュトークン（RT）
アクセストークンの再発行権（長期有効）。 -
CSRFトークン
リクエストの正当性検証用。
誰が生成して誰が持つか
トークンを生成するのはサーバーです。Cookieも同様にサーバーによって生成され、
生成したものをクライアントが保持することで、認可・認証の証明となっています。
保存先の種類と特徴
| 保存先 | 特徴 | セキュリティ |
|---|---|---|
| メモリ | ページ閉じると破棄。リロードで消える。 | 短命で比較的安全だが、JSからアクセス可能 |
| ローカルストレージ | 永続化可能。JSからアクセス可能。 | XSS攻撃で盗まれるリスク大 |
| Cookie | 自動送信可能。属性で制御できる。 |
HttpOnly・Secure・SameSiteでXSS/CSRF対策可能 |
基本的な運用例
| トークン種別 | 保存先 | 理由 |
|---|---|---|
| AT | メモリ（Bearer） | 短期有効。永続化せず盗難リスク低減 |
| RT | Cookie（HttpOnly） | 長期有効。JSからアクセスできないようにする |
| CSRF | Cookie |
SameSiteやDouble Submit CookieでCSRF防止 |
Cookieのセキュリティ設定
-
HttpOnly
JavaScript（document.cookie）から参照不可にする。XSSによるCookie窃取を防止。 -
Secure
HTTPS通信時のみCookieを送信。平文盗聴リスクを低減。 -
SameSite
他サイトからのリクエスト時にCookieを送信するかを制御。- Strict：同一サイトのみ送信
- Lax：安全なメソッドでのナビゲーション時は送信（デフォルト）
-
None：クロスサイトでも送信（
Secure必須）
トークン検証フロー（ざっくり）
まとめ
- トークンは認可・認証の証明
- サーバーが生成しクライアントが保持
- メモリ・LocalStorage・Cookieのいずれかで持つ
- ATRT CSRF Tokenがある
- CookieはHttpOnly、Scure、SameSiteなどがよく使われる