给定以下条件：
- 网站仅使用社交提供商来验证用户(Google/Facebook(。没有本机身份验证。
- 只有某些部分(例如产品评论(受到限制。
- 网站与服务器(同一域(通信。
最好的身份验证策略是什么？
- 仅使用社交提供者
在这种情况下：
- 我们需要研究每个提供程序的刷新/撤销令牌机制并实现它。
- 使用社交提供者来验证用户是否真实，但使用本机令牌
在这种情况下：
- 我们使用社交提供者验证用户是否真实。
- 我们生成自己的令牌并将其发送给客户端。
在我看来，第二种方法要好得多，因为：
- 无需研究如何根据每个社交提供商获取刷新令牌。
- 我们的服务器完全控制：到期时间控制。
- 撤销令牌也更容易(例如，更改我们自己服务器中的密钥(。 错误处理
- 更容易，因为在从社交提供者刷新令牌时不需要处理错误情况，而是可以实现我们自己的错误处理。
- 如果用户关闭窗口社交提供程序刷新令牌将在几个小时后过期，而我们的令牌不会。
- 如果使用社交提供商令牌，那么它们将在每个请求中从客户端发送到服务器，这比我们自己的令牌具有更高的安全风险(google/facebook中的用户敏感数据比我们的网站多得多(。此外，它们必须保存在客户端中的某个位置以实现持久性，这将再次带来更高的安全风险。
- 社交提供商令牌不携带任何特定于我们服务器的用户信息。这意味着更频繁地查询我们的数据库以识别用户，而不仅仅是将我们的用户 ID 放在令牌中(也许是 JWT 令牌(。
对我来说最大的缺点是我们必须为每个社会提供者维护多个刷新/撤销机制，而不仅仅是一个(我们自己的(。
在这种情况下，最佳做法是什么会很有趣。
联合登录感觉是最佳选择，它应该满足上述目标：
- 登录期间，应用程序将重定向到您的授权服务器 (AS(
- AS重定向到社交身份提供商 - 例如Facebook。
- 用户使用 Facebook 凭据登录
- 社交提供程序将令牌发布到 AS
- AS 生成自己的令牌以返回到应用
- 你的应用通过令牌中的 AS 用户 ID 标识用户
- 社交提供程序在下次登录之前不使用
例如，下面是指向 AWS 解决方案的链接，其中每个应用程序都可以选择其支持的社交提供商，并且可以根据需要禁用默认的 Cognito 登录选项。