ベアラトークン(Bearer Token).

ベアラトークンは「所持」だけで認証される資格情報で、API に提示できれば誰でもそのアクセス権を得られます。HTTP の Authorization: Bearer ヘッダーで送られ、OAuth 2.0 の枠組みで RFC 6750 として定義されています。所有証明がないため、TLS での伝送、安全な保管、狭いスコープ、短い有効期間が必須です。送信者拘束のあるトークン(DPoP、mTLS バウンド、Token Binding)はより安全な選択肢です。漏れたベアラトークンは失効するまで即座に悪用されます。

なぜ「所持のみ」の資格情報は破られ続けるのか

2023 年の 2 件が示している。Okta サポートシステム侵害(初期アクセスは 2023 年 9 月 28 日ごろ)では、攻撃者が顧客のアップロードした HAR ファイルを読み取り、そこに残っていた有効なセッション Cookie やトークンを再生して、BeyondTrust(10 月 2 日)や Cloudflare(10 月 18 日)といった顧客へ横展開した。別途、Storm-0558 作戦は盗んだ Microsoft の署名鍵で Azure AD/MSA のベアラトークンを偽造し、米国務省・商務省を含む約 25 組織の Exchange Online メールボックスに密かにアクセスした。いずれもトークンが「正規」であるがゆえに機能した——これこそベアラ方式の弱点である。

より堅牢な設計は、盗まれたトークンを無価値にする。送信者拘束(所有証明)トークンは、クライアントが呼び出しごとに保有を証明しなければならない鍵に資格情報を結び付ける。アプリケーション層では署名付き JWT ヘッダーによる DPoP(RFC 9449)、トランスポート層では cnf.x5t#S256 による証明書拘束の mTLS トークン(RFC 8705)である。いずれも FAPI 2.0 プロファイルで必須とされる。補完策として、短い TTL とリフレッシュのローテーション、オーディエンス/スコープの制限、デバイスやネットワーク文脈への束縛、異常検知時の即時失効が有効である。

flowchart TD
  C[Client] -->|Authorization: Bearer token| API[Resource server]
  API -->|token valid?| API
  API -->|yes| G[Grant access]
  L[Attacker steals token] -->|replays same token| API
  API -.no possession proof.-> G
  subgraph Mitigation
    D["DPoP / mTLS binds token to client key"] --> R[Stolen token rejected]
  end