0

我们正在尝试在基于 next+fastify 的应用程序中实现 Auth0。登录页面是自定义的，我们希望使用来自 fastify 服务器的嵌入式登录来集成登录。我对 oAuth 和 Auth0 很幼稚，对此我有一些疑问：

  1. 我们如何验证令牌？我们是否验证 JWT 并在服务器上维护令牌或快速化服务器，或者我们是否应该始终在 Auth0 端点上验证令牌？我尝试调用导致速率限制的userinfo端点。所以，我解释我们是否只是在服务器上验证 JWT 而不是发送到 Auth0 服务器。此外，我们在 cookie 中发送和维护 JWT 以始终验证客户端。理解是否正确？

  2. 嵌入式登录是否足够安全以用于生产？它周围有任何风险吗？

  3. 方法是否正确？有没有其他方法可以实现登录流程？我们还需要集成重置密码和其他功能。我已经阅读了 SDK 文档，它似乎对所有人都有支持。

非常感谢提前

4

1 回答 1

1
  1. 有几个选项可以验证 auth0 颁发的令牌，他们建议您利用中间件来验证令牌。多个框架都有自己的中间件来检查和验证 JWT。就像将中间件与您的应用程序集成并在您需要时执行验证一样简单。检查这个：

https://auth0.com/docs/tokens/json-web-tokens/validate-json-web-tokens

  1. 在我看来，使用 auth0 的通用登录选项总是更好，因为嵌入式登录有时会引发跨源身份验证问题。请记住，当用户尝试使用 auth0 登录您的应用程序时，它会将用户重定向到与为您的应用程序提供服务的域不同的另一个域。根据我的经验，使用通用登录可以为您提供有关用户登录过程的更多信息，这使得调试错误和身份验证过程的过程更加容易。您可以在此处阅读有关使用 auth0 登录的更多信息：

https://auth0.com/docs/login/embedded-login

https://auth0.com/docs/login/embedded-login/cross-origin-authentication

  1. 是的，您可以集成重置密码过程，这几乎完全由 auth0 自己处理。正如我之前所说，我们对我们的应用程序使用通用登录，因为它提供了对身份验证流程的更多控制。这并不意味着您不能使用嵌入式登录，它也是一个非常好的选择，但它似乎更专注于 UX 而不是控制身份验证流程。

如果您仍然对最佳方法有疑问，请查看此链接：https ://auth0.com/docs/universal-login/universal-vs-embedded-login

于 2021-07-15T15:06:13.843 回答