仅使用社交提供程序登录身份验证时，客户端和服务器之间的身份验证策略应该是什么? [英] What should be authentication strategy between client and server when only social providers login authentication is used?
问题描述
鉴于以下条件:
- 网站仅使用社交提供商来验证用户身份(Google/Facebook).没有本地身份验证.
- 仅某些部分(例如产品评论)受到限制.
- 网站与服务器(同一域)进行通信.
最佳的身份验证策略是什么?
What would be the best authentication strategy?
-仅使用社交服务提供商
在这种情况下:
- 我们需要研究每个提供商的刷新/吊销令牌机制并实现它.
-使用社交服务提供商来验证用户是否真实，但使用本机令牌
在这种情况下:
- 我们使用社交提供程序一次确认用户是真实的.
- 我们生成自己的令牌并将其发送给客户.
在我看来，第二种方法要好得多，因为:
It seems to me that the second approach is much better because:
- 无需研究如何根据每个社交提供商获取刷新令牌.
- 我们的服务器完全受控制:到期时间控制.
- 撤销令牌也更容易(例如，在我们自己的服务器中更改机密).
- 错误处理更加容易，因为从社交服务提供商处刷新令牌时无需处理错误情况，而是可以实施我们自己的错误处理.
- 如果用户关闭窗口，社交服务提供商的刷新令牌将在数小时内到期，而我们的令牌则不会.
- 如果使用社交服务提供者令牌，则将在每次请求时将其从客户端发送到服务器，这比我们自己的令牌具有更高的安全风险(google/facebook中的用户敏感数据比我们网站中的用户敏感数据要多得多).此外，还必须将它们保存在客户端中的某个位置以进行持久化，这又会带来更高的安全风险.
- 社交提供商令牌不携带任何特定于我们服务器的用户信息.这意味着对我们的数据库进行更频繁的查询以识别用户，而不仅仅是将我们的用户ID放入令牌中(也许是JWT令牌).
对我来说最大的缺点是，我们必须为每个社交提供者维护多个刷新/撤消机制，而不仅仅是一个(我们自己的).
The biggest disadvantage to me is that we have to maintain multiple refresh/revoke mechanisms per each social providers instead of just one (our own).
在这种情况下最好的做法是有趣的.
It would be interesting what would be the best practice in such case.
推荐答案
联合登录感觉是最好的选择，它应该满足您上述目标:
Federated sign in feels like the best option, which should meet the goals you've described above:
- 登录期间，应用程序重定向到您的授权服务器(AS)
- AS重定向到社交身份提供商-例如Facebook
- 用户使用Facebook凭据登录
- 社交提供者将令牌发布到AS
- AS生成自己的令牌以返回到应用程序
- 您的应用通过令牌中的AS用户ID识别用户
- 直到下一次登录时才使用社交提供程序
例如，这是 AWS解决方案，其中每个应用都可以选择其支持的社交服务提供商，并且可以根据需要禁用默认的Cognito登录选项.
As an example, here is a link to the AWS Solution, where each app can select the social providers it supports, and the default Cognito sign in option can be disabled if needed.
这篇关于仅使用社交提供程序登录身份验证时，客户端和服务器之间的身份验证策略应该是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
