RFC 8252 OAuth 2.0 for Native Apps ざっくりまとめ
※ 外部User Agent、埋め込みUser Agentといった独自用語の定義はTerminologyを参照
5 Using Inter-App URI Communication for OAuth
- ネイティブアプリは外部User Agent（一般的にはブラウザ）を使って認可要求を行わなければならない (MUST)
- ブラウザが持つSSOセッションや認証コンテキストを活用できる
6 Initiating the Authorization Request from a Native App
- ネイティブアプリ（Public Clientとなるもの）はPKCEを実装しなければならない (MUST)
- 認可要求を受け取る外部User Agentについて、本ドキュメントではブラウザを推奨する (RECOMMENDED) が、他の認可要求を扱う専用のアプリといった他の外部User Agentを利用してもよい (MAY)
- in-app browser tabがサポートされるプラットフォームでは、ユーザビリティのためにin-app browser tabの使用が推奨される (RECOMMENDED）
- in-app browser tab：ブラウザのタブをアプリから使う機能（ブラウザのセキュリティコンテキストを使うことができる）
7 Receiving the Authorization Response in a Native App
- 認可サーバーはネイティブアプリの認可応答受信方法について、少なくとも次の3つをサポートしなければならない (MUST)
- Private-Use URI Scheme Redirection：アプリ間で通信するための独自URIスキームを使う方法
- ネイティブアプリはドメインを逆順にしたURIスキームを使わなければならない (MUST)
- 例：
com.example.app:/oauth2redirect/example-provider
- Claimed "https" Scheme URI Redirection：httpsスキームのURIをアプリで受信する方法
- ネイティブアプリのIdentityを特定できるため、この方法が使えるプラットフォームはこれを使うべきである (SHOULD)
- Loopback Interface Redirection：httpスキームのループバックI/F（例：
http://127.0.0.1:12345/oauth2）を使う方法（デスクトップアプリなど特定のループバックI/Fポートを監視できるもの向け）- 認可サーバーはリダイレクトURIのうちポート番号を可変にしなければならない (MUST)
- ネイティブアプリはIPv4・IPv6両方のループバックI/F利用を試みて利用可能な方を使う、という実装が推奨される (RECOMMENDED)
8 Security Considerations
- 認可サーバーはPKCEを使わないPublic Clientからの認可要求を拒否すべきである (SHOULD)
- リダイレクトURIにhttpsスキームを使ったとしても認可コードの傍受のリスクは（Private-Use URIやLoopback Interfaceよりも低いが）残る
- Implicit GrantはPKCEを使えないため、ネイティブアプリでは推奨されない (NOT RECOMMENDED)
- Loopback Interfaceを使う場合は、認可要求から認可コード受信の間のみポートを開け、Redirect URIにはlocalhostではなくLoopback IPアドレスを使うべきある (SHOULD)
- 認可サーバーはネイティブアプリをPublic Clientとして登録しなければならない (MUST)
- 認可サーバーはクライアントにクライアントに完全なリダイレクトURIを登録を要求し、登録されたURIに完全一致しない（Loopback URIでのポート番号を除く）認可要求を拒否しなければならない (MUST)
- Private-Use URIを使う場合、認可サーバーはドメイン名の逆順のスキームを利用をすべきであり、少なくともピリオドを含まないURIは拒否すべきである (SHOULD)
- 認可サーバーはアプリのパッケージ名やバンドル名といった、クライアントのIdentityを検証するためのプラットフォーム依存の情報を要求してもよい (MAY)
- ネイティブアプリを共有鍵（Client Secret）で認証することは、クライアントIDをリクエストパラメータに入れる以上の意味を成さないため推奨されない (RECOMMENDED)
- 共有鍵でネイティブアプリを認証する場合も、認可サーバーはネイティブアプリをPublic Clientとして扱わなければならない (MUST)
- 認可サーバーはクライアントのIdentityが証明できない場合は、（過去に同意があったとしても）ユーザーとの対話なしに認可を進めるべきでない (SHOULD NOT)
- httpsスキームのリダイレクトURIの使用はIdentityの証明と扱ってもよい (MAY)、またプラットフォームによってはIdentityを証明する別の手段を用意していることもある。
- ネイティブアプリにおいても、アプリにおけるCSRF攻撃を防止するために、stateパラメータを使うことが推奨される (RECOMMENDED)
- Mix-up攻撃に対応するため、ネイティブアプリは認可サーバーごとに異なるリダイレクトURIを使わなければならない (REQUIRED)
- ネイティブアプリは認可要求時のリダイレクトURLパラメータを保管し、認可応答のURIと完全に一致することを検証しなければならない (MUST)
- 本ドキュメントでは外部User Agentとしてブラウザを推奨するが、他の外部User Agentについては言及しない。
- ネイティブアプリは認可要求に埋め込みUser Agentを使ってはならなく (MUST NOT)、認可サーバーは認可要求エンドポイントへの埋め込みUser Agentからのリクエストを検知してブロックしてもよい (MAY)
- 埋め込みUser Agentでは、ユーザーが入力した認証情報やCookieにアプリからアクセスできてしまう。
- First-partyアプリであっても、アプリに不要な権限を与えることとなり、またユーザーに正当なサイト以外でも認証情報を入力してよいと認識されてしまう。