開発者がサードパーティの認証に埋め込みユーザーエージェントを使用するのはなぜですか？代替案は何ですか？
OAuth（および他のフレームワークにも影響する可能性があります）の出現により、近年モバイルおよびデスクトップアプリの傾向に気づき、サードパーティを使用してサインアップまたはログインするようユーザーに要求しました認証プロバイダー。通常はTwitter、Facebook、Googleなどのソーシャルアカウントです。問題は、認証情報を入力するアプリを信頼できない場合に発生します。開発者がアプリが所有するダイアログ/ウィンドウにブラウザーを埋め込み、 表示されているページが正当なログインページであるかどうか、またはユーザーエージェント（ブラウザと上部のレイヤー）ができるかどうかを知る方法がない信頼される。
私は小規模なインディーズの開発者のアプリについても話していません。広く信頼されている会社のソフトウェアについて話しているのです（少なくとも、私がほとんどの時間を費やしているソフトウェア開発コミュニティでは）。過去数週間に見たいくつかの例：
- Atlassian Sourcetree を使用すると、Googleアカウントを使用してログインできます-Atlassianウィンドウ
- Postman GoogleログインはPostmanウィンドウで発生します
- Microsoft Visual StudioとOfficeはMicrosoftアカウントを使用してそれを行います（許可されています。これは、アプリが認証プロバイダーによって所有されているため、これは少し信頼されていますが、プロセスを承認しています）
- 一部のアプリは、たとえば、アプリ内のブラウザーウィンドウでPaypalにログインするように求めます
モバイルアプリに関して過去に寄せられた同様の質問（ただし、問題はモバイルに限定されません）：
デスクトップアプリに関する1つの質問：
接線方向に関連しているのは、Webアプリケーションでのiframeの使用です。
これは、認証してトークンを取得し、アプリに戻るためにアプリスペースからWebに移動するときの信頼の問題です。私は会社を信頼してソフトウェアをインストールするのに十分かもしれませんが、（すべての意図と目的のために）私のGoogleアカウントのマスターキーをソフトウェアに入力するのに十分ではありません。
この質問をさらに調査したところ、 このIETFドラフト が見つかりました：
埋め込みユーザーエージェントは、ネイティブアプリを認証するための代替方法です。ただし、埋め込みユーザーエージェントをホストするアプリは、OAuth Authorization Grantだけでなく、ユーザーの完全な認証資格情報にアクセスできるため、サードパーティによる承認サーバーの使用は安全ではありません。それはアプリのためのものでした。
編集：上記のドラフトは RFC8252 になりました。
および 古いディレクティブ、RFC6749 （2012年10月日付）は、他の興味深いヒントにも言及しています。
ほとんどの外部ユーザーエージェントにある視覚的保護にアクセスせずにリソース所有者が識別されていないウィンドウで認証しているため、埋め込まれたユーザーエージェントはセキュリティ上の課題を引き起こします。組み込みのユーザーエージェントは、認証のための身元不明の要求を信頼するようにエンドユーザーを教育します（フィッシング攻撃の実行を容易にします）。
私の質問：
これがフィッシング攻撃やMITM攻撃の機会が増えていることを心配するのは当然でしょうか（リアルタイムで資格情報やトークンを盗み、2FAを破る偽のまたはハイジャックされたブラウザ）。信頼できるソフトウェア自体が悪意のあるものとなる可能性はそれほど高くありませんが、その広範な使用により、エンドツーエンドの信頼を確認することができなくなり、ユーザーに要求するアプリに資格情報を盲目的に入力することを容認します（奨励することもできます）？
上記で引用した最後のセクションは確かに肯定的に答えると思いますが、私自身、特にソフトウェア開発者として、これに関するさらなるコメントと展望に興味があります。
これを行うための明白な「正しい」方法は、代わりに認証のためにユーザーを信頼できるブラウザーに転送することですが、これはユーザーエクスペリエンスを低下させる可能性があり、実際には問題を修正しません（悪意のある開発者がメインからウィンドウを開く可能性があります） はChromeのように見えますがありませんが、そうではありません-メインのブラウザウィンドウからのユーザーセッションは保持されません。
アプリ内の信頼できるソフトウェアスタック（アプリとレンダリングエンジン）をアプリ内で確実に使用できるように、アプリのユーザーエクスペリエンスを設計するためのより良い方法はありますか？そのような認証リクエストを模倣するのが難しい方法でデバイスレベルまたはシステムレベルで処理する必要がありますか？
私は実際にはセキュリティシーンに関与していません。ここに潜んでいるだけですが、これは業界でよく知られている懸念事項ですか？この種の認証フローを抑制する努力はありますか？
これがフィッシング攻撃やMITM攻撃の機会が増えていることを心配するのは当然でしょうか（リアルタイムで資格情報やトークンを盗み、2FAを破る偽のまたはハイジャックされたブラウザ）。信頼できるソフトウェア自体が悪意のあるものになる可能性はそれほど高くありませんが、その広範な使用により、ユーザーはエンドツーエンドの信頼を確認するのをやめます。
あなたは正しい100％です。結局のところ、ほとんどのユーザーはWebサイトが類似していることを期待しています。すべてのWebサイトに緑色の南京錠が付いている場合、ユーザーは大きな赤いセキュリティ警告に気づきます。すべてのWebサイトがユーザーの電子メールなどを要求すると、ユーザーは思い悩むことなく連絡先情報の配布を開始します。
同様に、アプリ内ブラウザを使用して認証情報を要求するアプリが増えると、ユーザーは「鈍感」になります。うまくいけば、これによりユーザーが最終的に点滅せずにサービス間で資格情報を共有することはありませんが、最悪のシナリオではそうなる可能性があります。
これを行うための明らかな「正しい」方法は、代わりにユーザーを信頼できるブラウザーに転送して認証することですが、これはユーザーエクスペリエンスを低下させる可能性があります
これらのステートメントはどちらも正しいです。
実際には問題を修正しません（悪意のある開発者がChromeのように見えるメインアプリからウィンドウを開く可能性がありますが、そうではありません-メインブラウザーウィンドウからのユーザーセッションは保持されません。ほとんどに気付かれませんでした）。
悲しいことに真実ですが、現時点では、ほとんどの場合、昔ながらのフィッシングです。悪意のあるユーザーはフィッシングWebサイトにもユーザーを誘導する可能性があります：/
アプリ内の信頼できるソフトウェアスタック（アプリとレンダリングエンジン）をアプリ内で確実に使用できるように、アプリのユーザーエクスペリエンスを設計するためのより良い方法はありますか？
残念ながらそうは思いません。
そのような認証リクエストを模倣するのが難しい方法でデバイスレベルまたはシステムレベルで処理する必要がありますか？
これは非常に興味深いです。 SEに関する関連質問 は、システムレベルのログインプロンプトに関するこの問題について説明します。その要点は、現在の実装/使用中のソリューションが存在しないことですが、いくつかの興味深いアイデアには、システムが所有していないウィンドウを閉じるショートカット/ボタンが含まれます。このようにして、システムは「続行するにはXYZを押してください」と言うことができ、それが実際にシステムでない限り、ウィンドウは閉じられ、資格情報は送信されません。
この特定のケースでは、OSは、上記と同様の機能を持つシステムブラウザインスタンスを持つことができます。このブラウザーは、OAuth用の簡単なAPIを備えた、1ページでハイパーリンクを参照しない、ログインのみのHTML/css/jsレンダラー/パーサーである可能性があります。
私は実際にはセキュリティシーンに関与していません。ここに潜んでいるだけですが、これは業界でよく知られている懸念事項ですか？
フィッシングの懸念は常に懸念事項です（少なくともすべき懸念事項です）が、私が個人的にOAuthなどのコンテキストで考えたのはこれが初めてです。
この種の認証フローを抑制する努力はありますか？
私はこの攻撃から保護するための取り組みについては知りませんが、 yubikeys などのu2fハードウェアスマートカードは、2faトークンを、それらが設定されている特定のWebサイトに暗号化します。これにより、フィッシングから保護されますが、悪意のある/偽のブラウザがユーザー名やパスワードなどを盗むことはありません。さらに、ユーザーがログインすると、悪意のある（アプリ内）ブラウザがセッションCookieを盗むだけです。
アプリケーション開発者向けに提案されたソリューション
OAuthはユーザーのデフォルトのブラウザnot in-appを介して実行する必要があります。
OS開発者向けの可能なソリューション
上記で説明したように、OSは理論的にはOAuthなどの信頼できる入力メソッドを提供できます。これにより、OAuthを超えて、ユーザーがCLIのgitなどのサービスに簡単かつ安全にログインできるようになります。
（私は信じていますが）広く認識され始めたのは懸念事項です。たとえば、RFC 8252はOAuth2について次のように述べています。
ネイティブアプリからのOAuth 2.0承認リクエストは、外部のユーザーエージェント、主にユーザーのブラウザーを介してのみ行う必要があります。 （ https://tools.ietf.org/html/rfc8252 ）。