现在不推荐使用密码授予的替代方法是什么？OAUTH 2.0

Question

• 我有一个内置于 Spring Boot 的 rest api。
  • React 中的前端应用程序。

我有用户应该能够登录并访问他们的信息，例如订单。现在为了让用户登录和注册，我认为最好使用 OAUTH。我开始研究 ouath 并发现授予密码是完美的案例。因为用户能够输入他们的凭据（用户名和密码），这些凭据（用户名和密码）进入 api 服务（也是授权服务器）并且可以进行身份​​验证和令牌将被传递，但后来我意识到它已被弃用，所以我想知道什么是最好的授权类型用于传递用户的用户名和密码以进行身份​​验证和授权。或者也许我错过了你们可以指出的非常简单的东西。

Answer 1

总结一下您的情况：您有自己的后端（某种类型的服务器，例如实现 REST API 的 Web 应用程序），用户应该能够使用用户名和密码登录以获得访问令牌，从而可以访问自己的资源在服务器上，他们应该能够通过您自己的前端（某种客户端，例如智能手机应用程序、桌面应用程序、单页应用程序等）来完成此操作。资源所有者密码授予完美地解决了您的问题，但现在它已被弃用:(

注意
OAuth 2.0 规范中表示，OAuth 2.0 授权框架使第三方应用程序能够获得有限的访问权限 [...]。在这种情况下，您的前端实际上并不是第三方应用程序，而是第一方应用程序，因此您不应该真正使用 OAuth 2.0，但最好使用有据可查的内容，而不是发明自己的解决方案来处理授权，所以就像你一样，我仍然会使用 OAuth 2.0。

简单的解决方案（已弃用）
继续使用资源所有者密码授予。它正是您想要的，并且是针对您的特定情况创建的（前端和后端来自同一“公司”）。

现在他们似乎已经决定 OAuth 2.1 不应该支持这样的第一方应用程序，但我想说将它用于您的情况仍然可以。如果 Google 或其他大型 OAuth 2.0 提供商支持此授予类型，情况会更糟，因为开发人员可能会创建自己的前端应用程序，并让用户通过直接在前端应用程序中输入 Google 用户名和密码来登录其前端应用程序，即向前端开发人员透露他们的 Google 凭据。我想他们不赞成这种资助类型的原因是为了避免这种情况。

更好的解决方案（已弃用）
使用隐式授予。在前端，当用户想要登录时，将用户重定向到后端（即在后端打开一个带有登录表单的网页，用户可以在其中输入用户名和密码），并且在用户成功登录后在后端，使用访问令牌将客户端重定向回前端。这样做的好处是用户仅向后端应用程序透露其密码，而绝不会向任何客户端应用程序透露密码。缺点是后端必须包含登录表单的网页，与纯 REST API 相比，实现起来有点复杂。如果你想正确地做到这一点，服务器应该有一个预先注册的客户端列表，其中包含 ID 和秘密，但如果你只有自己的前端，你需要支持我会说你可以跳过它或简单地硬编码客户端 ID在后端应用程序中。

不幸的是，这种补助类型也已被弃用......

正确的解决方案
使用授权代码授予（带有用于代码交换的证明密钥）。这种方式与上面描述的隐式授予非常相似，但不是使用访问令牌将用户重定向回前端，而是使用授权码将用户重定向回前端。然后，前端可以将此授权码发送到后端并取回访问令牌。

上面描述的或多或少只是授权代码授予。“使用代码交换证明密钥”几乎相同，但您还使用“密钥”来证明您是将该用户重定向到后端并用授权代码交换访问令牌（ “使用代码交换的证明密钥”部分基本上使其更加安全）。

当然，这里我只描述了总体思路，您需要查看规范以了解有关您应该发送的请求和响应的详细信息（请求正文应该是什么，使用什么状态代码等）。 ）。

Answer 2

OAuth 是专门为委托授权而设计的，即代表用户访问资源的授权。它不是为身份验证而设计的。OpenID Connect（构建于 OAuth 之上）专为身份验证而设计。

在委托认证/授权环境中，认证/授权任务由特定的独立服务执行。如果您的应用程序还管理身份验证/授权，也许您不需要 OpenID Connect/OAuth。

无论如何，资源所有者密码授予是最差的委派 OAuth 流程。它应该在非常罕见的遗留情况下使用，并且在 OAuth2.1 中已弃用。请参阅这篇文章了解更多详细信息。

要使用的 OAuth 流程主要取决于您的应用程序架构。请查看此处以确定哪种流程更适合您的需求。