OAuth 2.0.

OAuth 2.0(RFC 6749)では、リソース所有者(利用者)、クライアント(アプリ)、トークンを発行する認可サーバー、API を提供するリソースサーバーという 4 つの役割が分離されます。クライアントは定められたグラントを通じてアクセストークンを取得し――対話型アプリでは PKCE 付き Authorization Code(RFC 7636)、サービス間呼び出しでは Client Credentials、入力が困難な端末では Device Code(RFC 8628)を用いる――以後はそのトークンを Bearer 資格情報として付けて API を呼び出します。スコープと Audience によって、トークンで実行できる操作を制限します。

セキュリティ指針と落とし穴

RFC 9700(BCP 240、2025 年 1 月公開)は OAuth のセキュリティ実践をまとめたものです。Implicit グラントと Resource Owner Password Credentials グラントを非推奨とし、すべての Authorization Code クライアントに PKCE を義務付け、コード傍受やオープンリダイレクト攻撃を防ぐためにリダイレクト URI の完全一致を要求します。アクセストークンは Bearer 資格情報であるため、DPoP や相互 TLS で送信者を束縛(sender-constraining)すると、盗難後の再送(リプレイ)を制限できます。

現実世界で最も多い悪用は OAuth 同意フィッシング(不正な同意付与)です。攻撃者はパスワードを盗む代わりに悪意あるアプリを登録し、利用者を騙して広範なスコープを承認させます。2017 年 5 月の「Google Docs」ワームはこの手口でわずか 1 時間ほどで拡散し、APT29/Nobelium は Microsoft 365 の同意付与を繰り返し悪用して MFA を回避したまま永続化しました。防御策としては、管理者同意ワークフロー、発行元の検証、短命なトークン、未使用の付与の取り消しなどがあります。

flowchart LR
  U[リソース所有者] -->|1 認可 + code_challenge| AS[認可サーバー]
  AS -->|2 リダイレクト経由の認可コード| C[クライアントアプリ]
  C -->|3 コード + code_verifier| AS
  AS -->|4 アクセストークン| C
  C -->|5 Bearer トークン| RS[リソースサーバー / API]
  RS -->|6 保護されたデータ| C