アクセストークン.

アクセストークンは、リソース所有者がクライアントに与えた認可を表し、特定の権限とオーディエンスに制限されています。OAuth 2.0(RFC 6749)と OpenID Connect では、アクセストークンは不透明型 — 認可サーバーのイントロスペクションエンドポイント(RFC 7662)を呼び出して検証する — か、署名によってローカルで検証する自己完結型の JWT のいずれかです。通常は RFC 6750 に従って Authorization: Bearer ヘッダーで送信され、TLS 上を流れなければなりません。

単純なベアラートークンの本質的な弱点は、所持がそのまま権限を意味することです。ブラウザのストレージ、ログ、プロキシから盗まれたトークンは、誰でもリプレイできてしまいます。これが 送信者拘束型 トークンの台頭を促しました。RFC 8705 はトークンをクライアントの TLS 証明書に結びつけ(そのハッシュを cnf.x5t#S256 クレームに記録)、RFC 9449(DPoP)はトークンをクライアントが保持する鍵ペアに結びつけ、リクエストごとに新しい署名付き証明 JWT を要求するため、リプレイされたトークンは秘密鍵がなければ無意味になります。Lapsus$ で見られたセッション/トークンのリプレイや、各種の「パス・ザ・トークン」型クラウド侵入を含むトークン窃取攻撃こそ、これらの仕組みが防ぐ対象です。

ベストプラクティスは、短い有効期間(分単位)、狭いスコープ、オーディエンスと発行者の厳格な検証、alg: none の JWT トリックの拒否、更新のためのリフレッシュトークンとの併用、そしてトークンを JavaScript からアクセス可能なストレージに置かないことです。価値の高い API には、単純なベアラートークンよりも DPoP 拘束型または mTLS 拘束型のトークンを優先してください。

flowchart LR
  RO[リソース所有者] -->|同意を付与| AS[認可サーバー]
  C[クライアント] -->|トークン要求 + DPoP/mTLS 鍵| AS
  AS -->|短命のアクセストークン<br/>scope + aud + cnf クレーム| C
  C -->|ベアラートークン + 所持証明| RS[リソースサーバー / API]
  RS -->|署名検証/イントロスペクト<br/>aud, exp, 鍵束縛を確認| RS
  RS -->|許可または拒否| C