实际上比你描述的还要糟糕。任何后续用户都可以访问您在提供商处的用户帐户(例如 google/facebook 等),而不仅仅是您的应用程序。
你有没有找到处理这个的好方法?我在下面提供了一些建议,但我希望有更好的选择/正在筹备中。
从我的角度来看,您所描述的是一个真正的问题,并且是整个系统中的一个漏洞。正如您所指出的,使用 asp.net MVC,WebSecurity.Logout() 不会将用户从提供程序中注销。
在我提供了一些选项后,我将说明为什么我认为这是一个问题。这两种解决方案的关键在于,如果用户从他们的提供商注销,那么他们将无法在不重新验证的情况下登录您的网站,并且他们不会让他们的提供商用户帐户保持打开状态。
无论他们的提供商是什么,都将他们注销。如果他们的提供者是 facebook,那么请按照此答案中的说明进行操作。如果提供者是 google,您可以重定向到“ https://accounts.google.com/Logout ”。不幸的是,这有点笨拙,并且在供应商之间会有所不同。
当用户在您的站点上单击“注销”时,显示一条消息,指示他们应该从其提供商注销,然后直接转到提供商站点。例如,如果提供商是 google,那么当他们单击注销时,会显示一条消息,例如“请记住从 google 注销”,然后将他们定向到 www.google.com。这实际上不会将它们注销,但至少会保持一致。这是我正在使用的方法,直到我找到更好的方法。这并不理想,因为它将它们带出您的站点,但至少它们没有暴露于重大安全漏洞。
我认为让用户登录到提供程序是不好的原因如下例所示: -
- 用户在公共计算机上。
- 用户打开一个 EmergencyIceCream(虚构)站点。
- 在 EmergencyIceCream 网站上,用户选择使用提供商(例如 google/facebook)登录。
- 用户订购了他们的紧急冰淇淋并点击退出。
- 用户被带回 EmergencyIceCream 主页。
- 用户很高兴他们已注销。
- BadUser 来到电脑前,无法相信他们的运气,当他们访问提供商的网站(例如 google/facebook)时,他们可以访问和控制用户的帐户以及与用户帐户相关的任何应用程序(包括 EmergencyIceCream)。
我认为也应该有一个退出社交提供者的选项。我不确定这是否可以在 OAuthWebSecurity 的后台完成,或者是否需要在 open-id/oauth 实现中进行更改。我认为让代码分别注销每个提供程序并不是一个很好的选择。我不同意这就是 oauth 的工作方式,我们应该接受它或使用我们自己的身份验证和授权。作为使用 OAuthWebSecurity 功能来简化我的应用程序登录过程的消费者,我现在有更多工作要做,并且削弱了用户的安全性。此外,退出提供程序可以解决问题的事实表明有办法解决这个问题。