2

我正在为我的 Internet 应用程序实现 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

令牌撤销将意味着您的用户每次都必须授予您的应用程序共享数据的权限;他们不应该一直给予许可。

使用 Outh,您将登录过程外包给 FB 等,如果您登录到 FB,那么您也登录到您的应用程序(也称为单点登录)

…转到您的 FB 帐户并注销,然后再次启动您的应用程序,它现在应该提示并让您在需要时通过另一个 FB 帐户登录。

如果您想以自己的身份登录 FB,但以其他人的身份登录的应用程序,那么 OAuthWebSecurity 可能不是您的最佳设计选择。

于 2013-04-03T13:50:31.533 回答
0

每个提供者都必须在响应中包含“SignOutUri”,即 ExtraData.. 这有多难?

于 2013-08-13T18:35:51.027 回答