概要

OAuth 2.0のセキュリティベストプラクティス策定が進められている。
そのドラフトバージョン18の推奨事項(Recommendations)について個人用にメモする。

Protecting Redirect-Based Flows

Authorization Code Grant

クライアントは、攻撃者による認可コードのインジェクションを防止する必要がある。
クライアント側の対応
- PKCE(Proof Key for Code Exchange)を使用する
  - パブリッククライアントでの認可コードフローをどう保護するかを念頭に考えられた仕様
  - 認可コード横取り攻撃
    - カスタム URI スキームを上書きすることで、認可コードの受取先が異なるものとなり、認可コードを奪う攻撃。
    - 正当なアプリが開始した認可リクエストから、ユーザー認証に基づいて、攻撃アプリケーションに対してトークンが返却され、不正アクセスにつながる。
- パブリッククライアント(デバイスまたはデスクトップコンピューターあるいは Web ブラウザで実行されるアプリ。シークレットを安全に保持できない。)：PKCE必須
- コンフィデンシャルクライアント(サーバー上で実行されるアプリ。シークレットを安全に保持できる。)：PKCE推奨。
認可サーバー側の対応
- PKCEをサポートする。
  - PKCEのサポートをクライアント側から検出できるように、code_challenge_methods_supportedをメタ情報として公開する。
- code_challengeパラメーターが認可リクエストに存在する場合にのみ、code_verifierパラメーターを含むトークンリクエストを受け入れられるようにする。

Implicit Grant

Implicit Grant（response_type=token）などの認可サーバーが認可レスポンスでアクセストークンを返却する方式は、アクセストークンの漏洩などに対して脆弱である。
基本的に利用は非推奨。
クライアント側は、代替手段としてresponse_type=codeもしくはreponse_type=code id_tokenを利用することでアクセストークンを発行する必要がある。
- 認可サーバーがリプレイ攻撃を検出できる。
- アクセストークンがURLで公開されない。
- 認可サーバーが発行されたトークンを送信者に制約することができる。

Token Replay Prevention

Access Tokens

アクセストークン送信者は、受信者（リソースサーバーなど）側がそのトークンを受け入れるための条件として、特定の秘密情報を検証する必要がある。
認可サーバーとリソースサーバーは、TLSなど送信者を制約する方式を使用する必要がある。

Refresh Tokens

次のどちらかの対応を必須とする。
- 送信元制限
- リフレッシュトークンローテーション

Access Token Privilege Restriction

アクセストークンに関連付けられた権限は、特定アプリケーションまたはユースケースに必要な最小限に制限する。
- クライアントがリソースオーナーによって許可された権限を超えた操作を行うことを防ぐ。
ユーザーがそれぞれのセキュリティポリシーで許可されている権限を持たないようにする。
権限の制限により、アクセストークンの漏洩の影響を減らす。
- アクセストークンは、特定のリソースサーバー、できれば単一のリソースサーバーに制限する。
- 認可サーバーはアクセストークンを特定のリソースサーバーに関連付け、全リソースサーバーは、すべてのリクエストについて、そのリクエストで送信されたアクセストークンがその特定のリソースサーバーで使用されることを意図していたかを確認する必要がある。
  - 意図したものでない場合、リソースサーバーはそれぞれのリクエストを拒否する必要がある。
クライアントと認可サーバーは、パラメーター「scope」または「resource」を使用して、アクセスするリソースサーバーを決定できる（オプション）。
アクセストークンは、特定のリソースおよびリソースサーバー、またはリソース上のアクションに制限する必要がある。
- 認可サーバーはアクセストークンをそれぞれのリソースとアクションに関連付け、全リソースサーバーは、全リクエストについて、そのリクエストで送信されたアクセストークンがその特定のアクションに使用されることを意図していたか確認しなければならない。
  - 意図していない場合は拒否する必要がある。
クライアントと認可サーバーは、scopeスコープとauthorization_detailsを利用して、これらのリソースやアクションを決定する(オプション)。

Resource Owner Password Credentials Grant

使用しない。
リソースオーナーのクレデンシャルをクライアントに安全に公開できない。
クライアントが無害な場合も、クレデンシャルが認可サーバー以外にも漏洩する可能性があり、攻撃範囲が拡大する。

Client Authentication

認可サーバーは、クライアント認証を使用する必要がある。
mTLS [RFC8705]や private_key_jwt [OpenID]など、クライアント認証に非対称（公開鍵ベース）の方法を使用することが推奨される。
クライアント認証に非対称方式を使用する場合、認可サーバーは機微な対称鍵を保存する必要がないため、多くの攻撃に対して、より安全になる。

Other Recommendations

認可サーバーはOAuthメタ情報を公開し、クライアントはこのメタデータを使用して、自身を構成することを推奨する。
認可サーバーは、クライアントが「client_id」または「sub」の値、または本物のリソースオーナーとの混乱を引き起こす可能性があるその他のクレームに影響を与えることを許可すべきではない。
エンドツーエンドのTLSを使用することを推奨する。認可レスポンスは、暗号化されていないネットワーク接続を介して送信してはならない。
- そのために、認可サーバーは、ループバックインターフェイスリダイレクトを使用するネイティブクライアントを除き、「http」スキームを使用するリダイレクトURIを許可してはならない。

参考情報

OAuth 2.0 Security Best Current Practice draft-ietf-oauth-security-topics-18