我的用户应该能够登录并访问他们的信息，例如命令。现在为了让用户登录和注册，我认为使用 OAUTH 是一个最好的主意。我开始对 ouath 进行研究，发现授权密码是完美的案例。因为用户能够输入他们的凭证（用户名和密码），这些凭证（用户名和密码）进入 api 服务（也是授权服务器）并且可以进行身份验证并且令牌将被传递，但后来我意识到它已被弃用，所以我想知道什么是最好的授权类型用于传递用户的用户名和密码以进行身份验证和授权。或者我错过了一些你们可以指出的非常简单的东西。
【问题讨论】：
标签： oauth-2.0 spring-security-oauth2
总结一下您的情况：您有自己的后端（某种类型的服务器，例如实现 REST API 的 Web 应用程序），用户应该能够在其中使用用户名和密码登录以获得访问令牌，以便他们访问他们在服务器上拥有自己的资源，并且他们应该能够通过您自己的前端（某种客户端，例如智能手机应用程序、桌面应用程序、单页应用程序等）来执行此操作。 Resource Owner Password Grant 完美地解决了您的问题，但现在它已被弃用:(
注意
它在 OAuth 2.0 规范中说OAuth 2.0 授权框架使第三方应用程序能够获得有限的访问权限[...]。在这种情况下，您的前端并不是真正的第三方应用程序，而是第一方应用程序，因此您不应该真正使用 OAuth 2.0，但最好使用有据可查的东西，而不是发明自己的解决方案来处理授权，所以和你一样，我仍然会使用 OAuth 2.0。
简单的解决方案（已弃用）
继续使用资源所有者密码授予。它完全符合您的要求，并且是为您的特定情况创建的（前端和后端来自同一个“公司”）。
现在他们似乎已经决定 OAuth 2.1 不应该支持这样的第一方应用程序，但我会说它仍然可以用于您的情况。如果 Google 或其他大型 OAuth 2.0 提供商支持这种授权类型，情况会更糟，因为开发人员可能会创建自己的前端应用程序，并让用户通过直接在前端应用程序中输入他们的 Google 用户名和密码来登录他们的前端应用程序，即向前端开发人员透露他们的 Google 凭据。我想他们弃用这种 Grant Type 的原因是为了避免这种情况。
更好的解决方案（已弃用）
使用隐式授权。在前端，当用户想登录时，将用户重定向到后端（即在后端打开一个网页，用户可以输入用户名和密码的登录表单），并且在用户成功登录后在后端，使用访问令牌将客户端重定向回前端。这样做的好处是用户只向后端应用程序透露她的密码，而不会向任何客户端应用程序透露她的密码。缺点是后端必须包含登录表单的网页，与纯 REST API 相比，实现起来有点复杂。如果你想正确地做到这一点，服务器应该有一个带有 id 和秘密的预注册客户端列表，但是如果你只有自己的前端，你需要支持我会说你可以跳过它或者简单地硬编码一个客户端 id在后端应用程序中。
不幸的是，这种授权类型也已被弃用...
适当的解决方案
使用授权代码授予（带有用于代码交换的证明密钥）。这种方式与上面描述的隐式授权非常相似，但不是使用访问令牌将用户重定向回前端，而是使用授权码将用户重定向回前端。然后前端可以将此授权码发送到后端并取回访问令牌。
上面描述的或多或少只是授权码授予。 “用于代码交换的证明密钥”几乎相同，但您还使用“密钥”来证明您是将该用户重定向到后端的同一个客户端，并将授权代码交易为访问令牌（ “with Proof Key for Code Exchange”部分基本上使它更安全）。
这里我当然只描述了总体思路，您需要查看规范以了解有关您应该发送的请求和响应的详细信息（请求的正文应该是什么，使用什么状态码等）。
【讨论】：
OAuth 专为委托授权而设计，即代表用户访问资源的授权。 它不是为身份验证而设计的。 OpenID Connect（建立在 OAuth 之上）专为身份验证而设计。
在委托的身份验证/授权环境中，身份验证/授权任务由特定的独立服务执行。如果您的应用程序还管理身份验证/授权，那么您可能不需要 OpenID Connect/OAuth。
无论如何，资源所有者密码授予是最差的委托 OAuth 流程。它应该在非常罕见的遗留案例中使用，并且在 OAuth2.1 中已弃用。 详情请见this article。
要使用的 OAuth 流程主要取决于您的应用架构。 查看here 以确定哪种流程更适合您的需求。
【讨论】：