OAuth2.0 Security Best Current Practiceを読んでみる（１）

こんにちは、富士榮です。

昨日ポストした通り、OAuth2.0 Security Best Current PracticeがLast Callの段階に進みました。2024年2月22日までのレビュー期間を経て正式にRFCに向けたステップに進みます。

ということで少しだけこのドキュメントを見ていきたいと思います。

何に関するドキュメントなのか

Abstract、Introductionを軽く要約すると、

• 対象はRFC6749（The OAuth 2.0 Authorization Framework）、RFC6750（The OAuth 2.0 Authorization Framework: Bearer Token Usage）、そしてRFC6819（OAuth 2.0 Threat Model and Security Considerations）の3点
• OAuth2.0のフレームワークの活用が進むにつれ、当初想定していた以上に重要なシナリオ（金融やヘルスケア、行政サービスなど）でも利用されるようになってきた
• 当然さまざまな攻撃パターンも編み出されてきており、基本的にはRFC6819により対応してきてはいるが継続的に対応していくことが重要となってきている
• そのため、このドキュメントでは最新のセキュリティ上の推奨事項を提供する

ということになっています。

文章の構造

目次を眺めると、

• ベストプラクティス
• 攻撃モデルの更新
• 攻撃パターンと緩和策

という形になっています。

まずはベストプラクティスに従いアーキテクチャを設計を行い、RFC6819発行時点に加えて最新化された攻撃モデルを念頭に置きつつ、各攻撃パターンに対する緩和策を実装していく、という流れでシステム化を進めていく、という使い方が想定されているのだと思います。

今回はベストプラクティスの部分を見ておきましょう。

ベストプラクティス

以下のベストプラクティスが定義されています。

• リダイレクトベースのフローの保護
• 全体
• オープンリダイレクト対策として登録済みredirect_uriとの完全一致を検証すること
• CSRF対策をすること。PKCEやstateですね
• Mix up攻撃に対策すること
• 資格情報を含む情報をリダイレクトする際は誤って転送しないようにすること
• 認可コードグラントの場合
• 認可コードインジェクション対策を行うこと。PKCEですね
• インプリシットグラントの場合
• トークン漏えい対策をしない限りは使わないこと
• トークンリプレイ対策
• アクセストークン
• DPoP、mTLSなどの送信者制限トークンを利用すること
• リフレッシュトークン
• パブリッククライアントの場合は送信者制限を行うかローテーションを行うこと
• アクセストークンの権限の制限
• 必要最低限の権限に絞ること
• 特定のリソースサーバで利用するようにAudienceを絞ること
• リソースオーナーパスワードクレデンシャルグラント
• 利用してはならない
• クライアント認証
• 可能な限りクライアント認証を実装すること
• mTLSやprivate_key_jwtなどを用いることを推奨
• その他
• RFC8414のOAuth Authorization Server Metadataを使うことは有用であるため認可サーバはメタデータを公開することを推奨
• リソースサーバがクライアントを混同するような可能性のある属性を許可してはいけない
• クライアントとリソースサーバの間はTLSで保護されるべきである
• 認可応答はlocalhostおよびリダイレクトを使うネイティブアプリ（カスタムURIスキーム）を除き暗号化されていないネットワークを許可してはならない
• postMessageで認可応答を送信する場合は送信開始者と受信者の厳密な検証を行うこと
• 認可エンドポイントはユーザーエージェントが直接アクセスするためCORSを許可してはいけない

結構たくさんありますが、原則的なことが多いので実装する際のチェックとして利用すると良いと思います。

次回は続きを紹介したいと思います。