アクセストークン完全ガイド：OAuth2・JWTとOpaqueの違い、取得フローとセキュリティ対策
エバープレイ編集部アクセストークンとは — 概念と役割
アクセストークンは、システム（クライアント）に対して保護されたリソース（APIなど）へのアクセス権を一時的に付与する「資格情報」です。一般にOAuth 2.0の文脈で使われ、ユーザーやクライアントの認可情報を代替してAPIアクセスを行うために発行されます。アクセストークン自体は「誰が」「何に」「どの範囲で」アクセスできるかを示す情報（スコープ、発行者、有効期限など）を含みますが、その表現は実装によって異なります（JWTのような自己完結型トークンか、Opaqueな参照トークンか）。
アクセストークンの主な用途
- API認可：リソースサーバーがリクエストの正当性を判断するために使用。
- シングルサインオン（SSO）：複数サービス間で認証・認可情報を共有。
- モバイルアプリ・SPA：ユーザー認証後にバックエンドAPIへアクセスするための手段。
- サーバ間認証：マシン間のアクセス（クライアントクレデンシャルズフロー等）。
アクセストークンの形式
代表的な形式は次の2つです。
- 自己完結型トークン（例：JWT）：トークン内にクレーム（iss, sub, aud, exp, iat, scopeなど）と署名を含む。署名検証によりトークンの改ざん検出が可能で、リソースサーバーは発行者の公開鍵があれば外部参照なしに検証できる。利点は検証の高速さとスケーラビリティ。欠点は、有効期限が長い場合の無効化（リボーク）が難しい点。
- Opaque（不透明）トークン：ランダムな識別子であり、リソースサーバーは認可サーバーへイントロスペクション（照会）してトークン情報を得る。利点は発行側で容易に無効化できる点。欠点はイントロスペクションのためにネットワークコールが必要になること。
関連する標準とプロトコル
- OAuth 2.0（RFC 6749） — 認可フレームワークの基礎。
- Bearerトークン利用（RFC 6750） — HTTPでのトークン送信方法等。
- JWT（RFC 7519） — JSON Web Tokenの仕様。
- トークンイントロスペクション（RFC 7662） — 不透明トークンの検証方法。
- トークンリボーク（RFC 7009） — リフレッシュ・アクセストークン等の失効API。
- PKCE（RFC 7636） — 公開クライアント（SPAやネイティブ）向けのセキュリティ強化。
取得フローの概要（OAuth 2.0の代表的なフロー）
- Authorization Code フロー：認可サーバーでユーザー認証→認可コード発行→サーバー側でアクセストークン交換。サーバー側で機密を保持できる場合の推奨フロー。
- Authorization Code + PKCE：SPAやモバイルでクライアントシークレットを持てない場合の推奨改良版。
- Implicit フロー（廃止推奨）：ブラウザで直接アクセストークンを返す方式。セキュリティ上の理由から現在は非推奨。
- Client Credentials フロー：サーバー同士の認証でユーザーコンテキストが不要な場合。
- Resource Owner Password Credentials（旧来）: ユーザー名/パスワードを直接扱うため現代では推奨されない。
アクセストークンの検証ポイント
リソースサーバーは受け取ったアクセストークンを必ず検証する必要があります。主なチェック項目は：
- 署名（JWTの場合）やイントロスペクションでの有効性確認
- 有効期限（exp）を確認し期限切れを拒否
- 発行者（iss）が信頼できるか
- 対象（aud）が自サービスに合致しているか
- スコープ（scope）により操作権限を適切に制御
- リプレイ攻撃対策（jtiや短寿命トークン、TLSの利用）
セキュリティ上のベストプラクティス
- 常にTLS（HTTPS）を用いてトークンを送受信する。
- アクセストークンは短寿命に設定する（例：数分〜数時間）。
- 長期間の継続アクセスはリフレッシュトークンで実装し、リフレッシュトークンは厳格に保護する。
- SPAやモバイルではPKCEを用いる。クライアントシークレットを含めない。
- トークンは可能な限り安全なストレージに置く：ブラウザではHttpOnlyかつSecureなCookie（SameSite属性の利用）を検討し、localStorageはXSSリスクがあるため注意する。
- スコープを最小権限にする（必要な権限だけ付与）。
- トークンのローテーション（特にリフレッシュトークン）や失効リスト（ブラックリスト）を用いた失効管理を行う。
- ログと監査を行い異常な利用を検出（多頻度の使用や失敗率の急増など）。
リフレッシュトークンとトークンの無効化
アクセストークンは短命にして、長期的なセッション維持はリフレッシュトークンで行うのが一般的です。リフレッシュトークンを使って新しいアクセストークンを発行する際、回転（rotating refresh tokens）を採用すると、窃取時の被害を減らせます。トークンの取り消し（リボーク）はRFC 7009などで規定されており、リフレッシュ/アクセストークンの失効APIを提供することが望ましい。不可避に長い有効期限を設定する場合は、イントロスペクションやブラックリストによる失効管理が必要です。
よくある落とし穴と対策
- トークンのクライアント側保管を甘くする（localStorageに保存してXSSで漏洩） → HttpOnlyクッキーや短寿命トークン、XSS対策で防止。
- スコープやaudの検証を省略する → 最低限の検証を必ず行う。
- JWTを盲目的に信頼する（署名検証をしない、アルゴリズム不備） → 常に署名検証、適切なアルゴリズムの固定を行う。
- リフレッシュトークンの扱いを軽視する → 安全な保管、回転、失効APIの実装。
実装のヒントと運用
- 認可サーバーとリソースサーバーを分離し、公開鍵（JWKS）で署名検証を行う設計がスケーラブル。
- JWTを利用する場合は、必要なクレームのみを含め、機密情報は含めない。
- イントロスペクションやキャッシュの併用で性能とセキュリティを両立する（opaqueトークンの場合）。
- モニタリング：トークン発行数、失敗率、異常IP・UAでの使用などを監視。
まとめ
アクセストークンは現代のAPI駆動のシステムにおいて中心的な役割を持つ認可情報です。形式やフロー、運用の違いによってメリット・デメリットがあるため、用途（SPA、モバイル、サーバ間）に応じて適切な仕様（Authorization Code + PKCE、Client Credentials等）とトークン設計（短寿命、リフレッシュ、トークン形式）を採用することが重要です。また、TLSや適切な保管、署名検証、スコープ管理、失効手段など基本的なセキュリティ対策を徹底してください。
参考文献
- RFC 6749 — The OAuth 2.0 Authorization Framework
- RFC 6750 — The OAuth 2.0 Authorization Framework: Bearer Token Usage
- RFC 7519 — JSON Web Token (JWT)
- RFC 7662 — OAuth 2.0 Token Introspection
- RFC 7009 — OAuth 2.0 Token Revocation
- RFC 7636 — Proof Key for Code Exchange (PKCE)
- OWASP — JSON Web Token Cheat Sheet
- Auth0 — What is an Access Token?
- MDN — HTTP Authentication
投稿者プロフィール
