9

私はOAuth2.0プロトコルの研究をしています。

Webサーバーで実行されないデスクトップ/モバイルアプリケーションのベアラートークンを生成する問題で立ち往生しました。

OAuth 2.0プロトコルフローは、Webアプリケーションでは明らかです。ユーザーAliceに代わってmyapp.comアクセスしたいとすると、Aliceはにリダイレクトされるため、リソースマネージャーは、同意を取得した後、Aliceのブラウザーを、認証コードを収集し、それを使用してベアラートークンを取得するページにリダイレクトします。protectedresource.comhttps://protectedresource.com/oauth?redirect_uri=https://myapp.com/oauth&[...]

protectedresource.comドメインを認識myapp.comし、からのリクエストに対してのみベアラートークンを解放するため、これは正常に機能し、安全です。myapp.com

デスクトップアプリケーションを実行している場合、ブラウザがサポートされていても（つまり、HTMLビューアをWindowsフォームなどに埋め込んでいる場合）、同意後にアリスをリダイレクトするのはどこですか？

誰が認証コードを収集しますか？制御フローはどのように変化しますか？

デスクトップまたはAndroidで実行されているOAuth2.0実装の例を持っている人はいますか？

4

2 に答える 2

7

OAuth wiki には、使用できる多数のオプションがリストされていますが、そのすべてに欠点があります。最も単純な方法では、トークンをユーザーに表示できる Web アプリを実行し、ユーザーがトークン (および場合によっては更新トークン) をデスクトップ アプリにコピーします。

十分な時間があれば、カスタム URI をデスクトップ オペレーティング システムに登録する方法を調査し、それを として使用してredirect_uri、ブラウザーからアプリに自動的に転送することができます。これにより、最高のユーザー エクスペリエンスが得られます。

これらのシナリオでは、悪意のあるアプリは簡単にデスクトップ アプリになりすますことができ、セキュリティはユーザーが悪意のあるアプリをインストールしないことに依存します。

于 2012-12-07T19:18:02.273 に答える