OAuth 2.0 for Browser-Based Apps (Draft 2) ざっくりまとめ
5 First-Party Applications
- First-Party ApplicationにOAuth (OpenID Connect) を適用する場合もPassword GrantではなくAuthorization Code Flowを使うことが強く推奨される (RECOMMENDED)
- 認可サーバーをリダイレクトで切り離しておくことで、多要素認証や、シングルサインオン、外部IDP認証といった拡張をしやすくなる。
6 Architectural Considerations
- ブラウザアプリ（クライアント）とAPI（リソースサーバー）が同じドメインで提供される場合は、OAuth (OpenID Connect) の利点を享受できないため、セッションベースの認証の方がセキュリティリスクが低く適する
- ブラウザアプリのバックエンドでトークン処理を行う場合は、バックエンド自体はConfidential Clientになるが、アプリ全体としてはPublic Clientになる可能性もある
7 Authorization Code Flow
- ブラウザアプリはPKCEを実装しなければならない (MUST)
- ブラウザアプリはstateパラメータでCSRF対策をしなければならない (MUST)
- 認可サーバーはリダイレクトURIを完全一致で検証すべきである (SHOULD)
8 Refresh Tokens
- 認可サーバーはブラウザアプリに対してRefresh Tokenを発行すべきでない (SHOULD)
- Refresh Tokenを発行する場合はRefresh Token Rotationに対応しなければならない (MUST)
9 Security Considerations
- 認可サーバーはブラウザアプリをPublic Clientとして登録しなければならない (MUST)
- 認可サーバーはブラウザアプリに1つ以上のリダイレクトURLの登録を要求しなければならない (MUST)
- ブラウザアプリを共有鍵（Client Secret）で認証することは、クライアントIDをリクエストパラメータに入れる以上の意味を成さないため推奨されない (RECOMMENDED)
- 共有鍵でブラウザアプリを認証する場合も、認可サーバーはブラウザアプリをPublic Clientとして扱わなければならない (MUST)
- クライアントのIdentityを保証できない場合、認可サーバーは認可要求を（以前の同意に基づいて）ユーザー操作なしに処理すべきでない (SHOULD)
- リダイレクトURIをHTTPSの固定URLとすることをクライアントのIdentity証明とみなしてもよい (MAY)
- Mix-up攻撃を防ぐために、クライアントは認可サーバーごとに異なるリダイレクトURIを使い、認可要求時にリダイレクトURIをセッションに保存して、認可レスポンスの送信元を検証しなければならない (MUST)
- 認可サーバーはブラウザアプリに必要なCORSヘッダをサポートしなければならない (MUST)
- ブラウザアプリはContent-Security-Policyなどの仕組みで特定の静的にホストされたスクリプトのみ実行できるように制限すべきである (SHOULD)
- （9.8章に記載されるImplicit Grantに対する脅威については省略）