0

鉴于以下条件：

  1. 网站仅使用社交服务提供商来验证用户身份（Google/Facebook）。没有本机身份验证。
  2. 只有某些部分（例如产品评论）受到限制。
  3. 该网站与服务器（同一域）进行通信。

最好的身份验证策略是什么？

- 仅使用社交服务提供商

在这种情况下：

  1. 我们需要研究每个提供者的刷新/撤销令牌机制并实现它。

- 使用社交提供者来验证用户是真实的，但使用原生令牌

在这种情况下：

  1. 一旦用户是真实的，我们就会使用社交提供者进行验证。
  2. 我们生成自己的令牌并将其发送给客户端。

在我看来，第二种方法要好得多，因为：

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

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

在这种情况下，最好的做法是什么会很有趣。

4

1 回答 1

1

联合登录感觉是最好的选择，它应该满足您上面描述的目标：

  • 在登录期间，应用程序重定向到您的授权服务器 (AS)
  • AS 重定向到社交身份提供者 - 例如 Facebook
  • 用户使用 Facebook 凭据登录
  • 社交提供者向 AS 发布令牌
  • AS生成自己的token返回给app
  • 您的应用通过令牌中的 AS 用户 ID 识别用户
  • 在下次登录之前不使用社交提供者

例如，这里有一个指向AWS 解决方案的链接，每个应用程序都可以在其中选择它支持的社交服务提供商，如果需要，可以禁用默认的 Cognito 登录选项。

于 2020-01-02T08:18:31.447 回答