2

インターネット アプリに ASP.Net MVC の OAuthWebSecurity を実装しています。Facebook、Twitter、Google、および Yahoo を使用して正常に認証できます。これらのそれぞれで初めて認証を行うと、それぞれのサイトに送られ、アプリケーションが承認されます。理にかなっています。

ただし、Facebook、Google、および Yahoo での後続の認証試行では、プロバイダーの認証画面が表示されません。Twitterは毎回私に尋ねているようです。

これは問題ですか？別の人が私のコンピューターを使用し、Facebook 認証を使用して私のアプリを使用した場合、その人は私として認証されますか? oAuth の結果はどのようにキャッシュされますか? それらをどのようにクリアしますか？

ありがとう。

4

3 に答える 3

3

それは実際にはあなたが説明するよりも悪いです。後続のユーザーは、アプリケーションだけでなく、プロバイダー (google/facebook など) でユーザー アカウントにアクセスできます。

これを処理する良い方法は見つかりましたか？以下にいくつかの提案をしましたが、パイプラインで利用可能なより良いオプションがあることを願っています.

あなたが説明したことは、私の観点から見ると、システム全体の本当の問題であり、ちょっとした穴です。あなたが示すように、asp.net MVCを使用すると、 WebSecurity.Logout() はユーザーをプロバイダーからログアウトしません。

いくつかのオプションを提供した後、なぜそれが問題だと思うのかを示します。両方のソリューションの重要な点は、ユーザーがプロバイダーからログアウトすると、再認証せずにサイトにログインできなくなり、プロバイダーのユーザー アカウントを開いたままにできないことです。

  1. プロバイダーが何であれ、ログオフします。プロバイダーが facebook の場合は、この回答の指示に従ってください。プロバイダーが google の場合、「 https://accounts.google.com/Logout 」にリダイレクトできます。残念ながら、これは少し扱いに​​くく、プロバイダーによって異なります。

  2. ユーザーがサイトで「ログアウト」をクリックすると、プロバイダーからログオフしてからプロバイダー サイトに移動する必要があることを示すメッセージが表示されます。たとえば、プロバイダーが Google の場合、ユーザーがログオフをクリックすると、「忘れずに Google からログオフしてください」などのメッセージが表示され、www.google.com に誘導されます。これにより、実際にログオフされるわけではありませんが、少なくとも一貫性は保たれます。これは、より良いものが見つかるまで私が使用しているアプローチです。それらをサイトから排除することは理想的ではありませんが、少なくとも大きなセキュリティ上の欠陥にさらされることはありません.

ユーザーをプロバイダーにログインさせたままにしておくことが悪いと私が考える理由は、次の例で示されます。

  1. ユーザーは公共のコンピューターを使用しています。
  2. ユーザーが EmergencyIceCream (架空の) サイトを開きます。
  3. EmergencyIceCream サイトで、ユーザーはプロバイダ (例: google/facebook) を使用してログインすることを選択します。
  4. ユーザーが緊急アイスクリームを注文し、[ログアウト] をクリックします。
  5. ユーザーは、EmergencyIceCream ホームページに戻ります。
  6. ユーザーはログアウトしたことに満足しています。
  7. BadUser がコンピューターにアクセスし、プロバイダーのサイト (例: google/facebook) にアクセスして、ユーザーのアカウントとユーザーのアカウントに関連付けられたアプリケーション (EmergencyIceCream を含む) にアクセスして制御できるという幸運を信じることができません。

ソーシャルプロバイダーからもログアウトするオプションがあるべきだと思います。これが OAuthWebSecurity の内部で実行できるものなのか、open-id/oauth 実装で変更する必要があるのか​​ はわかりません。各プロバイダーから個別にログアウトするコードを用意することは、あまり良い選択肢ではないと思います。これが oauth の仕組みであり、それと一緒に暮らすか、独自の認証と承認を使用する必要があることに同意しません。アプリのログイン プロセスを簡素化する OAuthWebSecurity 機能の利用者として、やるべきことが増え、ユーザーのセキュリティが弱体化しています。また、プロバイダーからログアウトすると問題が解決するという事実は、これを解決する方法があることを示しています。

于 2013-06-09T23:20:12.500 に答える
0

各プロバイダーは、応答、つまり ExtraData に「SignOutUri」を含める必要があります。

于 2013-08-13T18:35:51.027 に答える
0

トークンの取り消しは、ユーザーが毎回アプリにデータを共有する許可を与える必要があることを意味します。許可を与え続ける必要はありません。

Outh を使用すると、ログイン プロセスを FB などにアウトソーシングしています。FB にログインしている場合は、アプリにもログインしています (別名シングル サインオン)。

…fb アカウントに移動してログオフし、アプリを再度起動すると、プロンプトが表示され、必要に応じて別の FB アカウントを介してログインできるようになります。

自分として FB にサインインしたままにして、別の誰かとしてアプリにサインインしたい場合、 OAuthWebSecurity はおそらく最良の設計選択ではありませんでした。

于 2013-04-03T13:50:31.533 に答える