Googleは中間者攻撃対策として、OAuth 2.0のAuthorization RequestをEmbedded User-Agent（埋め込みブラウザ）を利用して実装することを禁止（ブロック）している。これに関連して、OAuth 2.0・OpenID Connect仕様やIDaaSのドキュメントを参考に、認可サーバー（IDプロバイダ）としてEmbedded User-Agentについてどのような扱いとすべきか（とその理由）を整理した。
まとめ
- 3rd Partyからの認可（認証）リクエストでのEmbedded User-Agentの利用は、クライアントがユーザーのクレデンシャルにアクセスできてしまうため、3rd Partyでは禁止とすべき。
- 認可サーバー（OpenIDプロバイダ）視点では、審査等で落としたり、埋め込みブラウザをUser-Agentヘッダ等で検知してブロックするなど、開発者が（うっかり）Embedded User-Agentを利用しないように対策を取るとよい。
- ただし、HTTPリクエストである以上、UA偽装などをされてしまうと埋め込みブラウザからのリクエストをサーバー側で確実にブロックすることはできない。このため、当面（セキュリティソフトやプラットフォームで制限する仕組みが導入されない限り）は正規のクライアントで使われないように＋ユーザーがEmbedded User-Agentに対して警戒できるように、というのがセキュリティ的な意義となる。
- First Partyにおいても、攻撃を受ける範囲を狭める、クレデンシャル入力時のURLやTLS証明書の検証をユーザーに推奨できるため、Embedded User-AgentではなくExternal User-Agentを利用するのがよい。
- UX的には、External User-Agentを利用することで他のアプリとログイン状態を共有できたり、パスワードマネージャを利用できたり、というメリットがある。Android、iOSに関してはin-appブラウザを利用することでアプリ切り替えによるUX低下も解消できる。
調査メモ
OAuth 2.0 (2.1 draft)
- RFC8252 - OAuth 2.0 for Native Apps - 8.12. Embedded User-AgentsにはEmbedded User-Agentの使用は禁止（MUST NOT）という記載があるが、OAuth 2.1 draft 01 - 9.20. Embedded User Agents in Native Appsでは非推奨というニュアンスの記載に留められている。
- Embedded User-Agentを禁止（非推奨）とする理由はどちらの仕様も同じで、アプリがユーザーのクレデンシャルにアクセスできてしまうため、となる。（典型的なWebViewでは、キーストロークの記録や、フォーム自動送信による同意回避、セッションCookieの取得も可能とのこと。）
- 3rd Partyに対してはもちろんであるが、First Partyに対しても、攻撃を受ける範囲（クレデンシャルを受け付けるI/F）を狭める、クレデンシャル入力時のURLやTLS証明書の検証をユーザーに推奨する、という意味合いがあるとのこと。
- ユーザービリティ的にはExternal User-Agentを使うことで他のアプリと認証状態と共有できるというメリットも挙げられている。
- Googleは中間者攻撃によるフィッシング対策として、WebViewやEmbedded Browser Framework（Chromium Embedded Frameworkなど）からのAuthorization Requestをブロックしている。
- とはいえAuthorization Requestは本質的には単なるHTTPSリクエストとなるため、Embedded User-Agentを認可サーバーで確実にブロックするということはできないのでは、というコメントがQ&Aサイトに寄せられている。
Auth0
- OAuth仕様を引き合いにEmbedded User-Agentsの利用は非推奨としている。
- .NET用SDKでもWebViewでのログイン画面表示対応の要望はリジェクトされている。