仅使用社交提供程序登录身份验证时,客户端和服务器之间的身份验证策略应该是什么?

问题描述 投票:0回答:1

考虑到以下条件:

  1. 网站仅使用社交服务提供商来认证用户(Google / Facebook)。没有本地身份验证。
  2. 仅限制某些部分(例如产品评论)。
  3. 网站与服务器通信(同一域)。

最佳的身份验证策略是什么?


-仅使用社交服务提供商

在这种情况下:

  1. 我们需要研究每个提供商的刷新/吊销令牌机制,并实施它。

-使用社交服务提供商来验证用户是真实的,但使用本机令牌

在这种情况下:

  1. 我们使用社交提供程序确认用户真实存在。
  2. 我们生成自己的令牌并将其发送给客户端。

在我看来,第二种方法要好得多,因为:

  1. 无需研究如何获取刷新令牌,具体取决于每个社交提供者。
  2. 我们的服务器处于完全控制权:到期时间控制权。
  3. 撤销令牌也更容易(例如,在我们自己的服务器中更改机密)。
  4. 错误处理更加容易,因为在从社交提供者处刷新令牌时无需处理错误情况,而可以实施我们自己的错误处理。
  5. 如果用户关闭窗口,社交提供者的刷新令牌将在数小时内到期,而我们的令牌不会。
  6. 如果使用社交服务提供者令牌,则将在每次请求时将它们从客户端发送到服务器,这比我们自己的令牌具有更高的安全风险(google / facebook中的用户敏感数据比我们网站中的用户敏感数据多得多)。另外,还必须将它们保存在客户端中的某个位置以保持持久性,这又会带来更高的安全风险。
  7. 社交服务提供商令牌不携带任何特定于我们服务器的用户信息。这意味着对我们的数据库进行更频繁的查询以识别用户,而不仅仅是将我们的用户ID放入令牌(也许是JWT令牌)。

对我来说最大的缺点是,我们必须为每个社交提供者维护多个刷新/撤消机制,而不仅仅是一个(我们自己的)。

在这种情况下,最佳实践是很有趣的。

authentication oauth-2.0 google-oauth2 facebook-oauth social-authentication
1个回答
0
投票

联合登录感觉是最好的选择,它应该满足您上述的目标:

  • 在登录期间,应用程序重定向到您的授权服务器(AS)
  • AS重定向到社交身份提供者-例如Facebook
  • 用户使用Facebook凭据登录
  • 社交提供者将令牌发布到AS
  • AS生成自己的令牌以返回到应用程序
  • 您的应用从令牌中的AS用户ID识别用户
  • 直到下一次登录时才使用社交提供者

例如,这是指向AWS Solution的链接

© www.soinside.com 2019 - 2024. All rights reserved.