Access Tokenとは?仕組み・種類・セキュリティと実運用のベストプラクティス

Access Tokenとは何か — 概要と役割

Access Token(アクセストークン)は、認可(Authorization)および認証(Authentication)においてクライアントがリソースサーバ(APIなど)へアクセスするために提示する一時的な資格情報です。アクセストークンは「誰が」「何を」「どの範囲で」できるかを示す情報(権限や有効期限、対象リソースなど)を含み、リソースサーバはトークンを受け取り検証することでアクセスを許可または拒否します。例えばOAuth 2.0やOpenID Connectのエコシステムで広く使われています。

アクセストークンの主な種類

  • ベアラートークン(Opaque/Bearer): トークン自体はランダムな文字列で内部構造を持たない。リソースサーバは認可サーバへ照会(introspection)して有効性や権限を確認する。多くの商用認可サーバが提供する既定の方式。
  • JWT(JSON Web Token): トークンを自己完結的に表現する形式。ヘッダ・ペイロード・署名で構成され、公開鍵で検証可能。署名(または暗号化)によりトークンの改ざん検出が可能で、認可サーバとリソースサーバが鍵を共有すれば照会なしに検証できる。
  • SAMLトークン: 主にエンタープライズ用途のXMLベースのトークン形式。Web SSOやシングルサインオンで使われる。

アクセストークンの発行と検証の流れ(典型)

代表的な流れとしては、クライアントが認可サーバへ認可要求を送り、ユーザーの同意や認証が行われると認可サーバがアクセストークンを発行します。以降、クライアントはHTTP Authorizationヘッダ("Authorization: Bearer <token>")などにトークンを付与してリソースサーバへリクエストを送ります。リソースサーバはトークンを検証し、問題なければリクエストを処理します。検証方法はトークンの種類によって異なります(JWTなら署名検証とクレーム確認、Opaqueならintrospection)。

JWTの構造と検証ポイント

JWTはヘッダ、ペイロード(クレーム)、署名の3部構成です。主なクレームにはiss(発行者)、sub(主体/ユーザーID)、aud(対象オーディエンス)、exp(有効期限)、iat(発行時間)、scope/rolesなどがあります。検証の基本は次の通りです。

  • 署名検証:認可サーバが使った鍵(対称鍵または公開鍵)で改ざんがないことを確認。
  • 発行者とオーディエンス確認:issとaudが期待する値と一致するか。
  • 有効期限チェック:exp/nbf/iatを確認し期限内か判断。
  • アルゴリズム固定:鍵を使った検証時にalg混在攻撃を防ぐため、期待するアルゴリズムのみ受け入れる。

OAuth 2.0 の代表的フローとアクセストークンの関係

代表的なフローは以下の通りです。選択するフローはクライアントの種類(機密クライアントか公開クライアントか)やユースケースによって異なります。

  • Authorization Code Flow(推奨): サーバサイドアプリやSPAでPKCEを併用。認可コードをアクセストークンに交換。
  • Implicit Flow(非推奨): ブラウザ単体でトークンを直接取得する方式。セキュリティ上の理由で現在は避けられる。
  • Client Credentials Flow: サービス間通信でクライアントが直接アクセストークンを取得する。
  • Resource Owner Password Credentials(非推奨): ユーザーのID/パスワードを直接扱う方式で、回避が推奨される。
  • Device Flow、Refresh Token Flowなど: 特殊デバイスや長期セッションのための手法。

アクセストークンのセキュリティベストプラクティス

アクセストークンは機密情報として扱い、漏えいや不正利用を防ぐために次の対策を講じるべきです。

  • 短い有効期限(TTL): トークンは短く設定し、長期のアクセスはリフレッシュトークンで行う。
  • Refresh Tokenの安全な取り扱い: Publicクライアントではrefresh tokenの取扱いに注意し、可能なら回転(rotation)を採用する。OAuth 2.0 Security Best Current Practiceはリフレッシュトークンの回転と利用済みトークンの無効化を推奨しています。
  • HTTPS/TLSの常時使用: トークンは必ずTLSで保護されたチャネルを通じて送る。HTTPは絶対に不可。
  • 保存場所の慎重な選定: WebアプリではLocalStorageにトークンを置くとXSSで盗まれるリスクがあるため、可能ならSameSiteかHttpOnlyのセキュアCookieを利用するか、短期トークン+CSRF対策を採る。
  • スコープと最小権限の原則: トークンには必要最小限の権限のみ付与する。細かいスコープ設計が重要。
  • 署名検証・鍵管理: JWTを使用する場合、公開鍵(JWKS)のローテーションとキャッシュ戦略を整備する。kidヘッダで鍵の切り替えに対応する。
  • トークン破棄(revocation)とintrospection: 緊急停止やログアウト時にトークンを無効化する仕組みを用意し、必要に応じてintrospectionエンドポイントで検証する。
  • 盗難・リプレイ対策: 同一トークンの多地点利用や不自然な利用パターンを検知する。DPoPやtoken binding、mTLSなどのPoP(Proof-of-Possession)技術でリプレイリスクを低減できる。

フロントエンドとモバイルでの注意点

シングルページアプリ(SPA)やネイティブモバイルアプリでは、クライアントが“公開”クライアントであるためシークレットを保持できません。推奨される対策はPKCE(Proof Key for Code Exchange)の利用、Refresh Tokenの取り扱いにおける回転、セキュアなストレージ(KeychainやSecure Enclave等)使用、XSS対策の徹底です。ブラウザではHttpOnly Cookieを使うとXSSから守れる一方、CSRF対策が必要になります。

アクセストークンの運用と監視

運用面では以下が重要です。

  • 発行ログと使用ログの収集:どのクライアントがどのエンドポイントへいつアクセスしたかを記録し、異常検知に利用する。
  • メトリクスとアラート:異常なトークン要求頻度、異常IP、地域外アクセスなどを検出するアラートを整備する。
  • 鍵(鍵セット)管理:定期的な鍵ローテーションと、ロールバック時の互換性を考慮。公開鍵はJWKSエンドポイントで配布するのが一般的。
  • リスク対応プロセス:トークン漏洩が判明した場合の速やかな無効化(revocation)と影響範囲の通知手順を用意する。

高度なトピック:Proof-of-Possession、トークン交換、mTLS

より強固なセキュリティが必要な場面では次の技術を検討します。

  • DPoP(Demonstration of Proof-of-Possession): トークン使用時に使用者が秘密鍵の所有を示す短期証明を付与してリプレイを防ぐ仕組み。
  • mTLS(Mutual TLS): クライアント証明書によりクライアント認証を行うことで、トークンの横取り後でも不正利用を難しくする。
  • トークン交換(RFC 8693): あるトークンを別のトークンへ交換して権限を限定したり、異なるドメイン間での委任を実現する。

設計上のよくある落とし穴とその回避策

  • トークンを永続的に長く設定する:長期トークンは盗難時の被害が大きくなるため避ける。
  • スコープが粗すぎる:"read"や"write"だけの大まかな分け方は権限分離が難しくなる。リソース単位の細かいスコープ設計を検討する。
  • 署名アルゴリズムの緩和:"alg"を信用せず期待するアルゴリズムを固定する。Noneアルゴリズムやalg差し替え攻撃に注意。
  • 秘密鍵の露出:認可サーバの秘密鍵やクライアントシークレットをコードやリポジトリにハードコーディングしない。

法務・コンプライアンス上の注意

アクセストークンは個人データや機密情報へのアクセスを媒介するため、GDPR等の規制下ではトークンの管理とログ監査が求められる場合があります。トークンに含めるクレームは最小限にとどめ、個人が特定されうる情報(PII)を不用意にペイロードへ入れないことが望まれます。

まとめ

アクセストークンはモダンな認可アーキテクチャの中心にあり、その設計・運用はセキュリティと可用性の両面で重要です。トークン形式の選択(opaque / JWT)、発行フロー(Authorization Code + PKCE など)、保存と送信のセキュリティ、そして運用での監視と鍵管理を総合的に設計することで、安全かつ使いやすい認可基盤を構築できます。最新のベストプラクティス(リフレッシュトークン回転、PKCE、短いTTL、DPoPやmTLSの活用)は積極的に採用を検討してください。

参考文献