Authentication OAuth密码授权替换

我目前正在围绕OAuth2和OIDC进行研究。我知道所有的授权类型是什么（即授权类型“授权码”、“客户端凭据”、“设备令牌”和“刷新令牌”）。但是，这四种授权类型不包括传递用户名和密码的选项。我知道有一个密码流，但是根据协议，这种授权类型是被禁止的

我也遇到了密码流的问题，但我不知道如何替换它——毕竟，用户需要在某个时候输入他们的凭据

---

我有什么遗漏吗？我原以为只有一个可信的客户端使用密码流，当用户想要登录时，所有其他客户端都会被重定向到该客户端。

我想我现在对这个问题有了更好的理解，尽管我可能会在这里对您的问题提出我自己的要求

密码授予流以前允许单个客户端使用API对多个终端用户进行身份验证。假设你经营一家商店，你的快递公司有一个API。您的店铺设置了一个客户，您的每位员工都可以通过该客户登录到自己的帐户。 在这种情况下，要登录，他们需要提供客户端ID和密码，以及密码授予允许的用户名和密码。 但是，为了将用户凭据传递给API，客户端需要以纯文本形式处理它们

这就是授权代码流接管的地方。本质上，它将登录过程推迟到API，用户在那里输入他们的凭据。 但是如果你的客户是API用户呢？商店用户登录到商店应用程序，商店应用程序使用交付API作为商店而不是终端用户进行身份验证

在这里，客户端凭据授予是合适的选择。协议中提到了“在用户上下文之外”使用客户机凭据授权，但这并不意味着客户机本身不能在由客户机ID和secret标识和验证的API中与用户关联。 在这种情况下，客户端拥有处理登录到API所需的所有凭据，而无需用户干预

---

在API处理终端用户身份验证的任何情况下，都可以期望用户积极参与该过程，从而能够通过身份验证代码流与API提供的登录屏幕进行交互。

我遇到了完全相同的问题。我有一个API，需要允许客户端作为用户进行身份验证，但客户端的用户在客户端系统上有自己的帐户，因此无法与客户端向API进行身份验证的用户帐户进行交互。密码流是唯一合适的方法。API的凭据保存在客户端服务器中，不向用户公开，因此密码流肯定是合适的？我认为不推荐密码授予没有考虑到这样一种情况，即客户端需要使用API作为用户进行身份验证，但登录到客户端的用户与客户端登录的用户不同作为API的一部分。