Kon*_*ten 4 security authentication authorization oauth-2.0
我们在选择合适的安全流程方面存在争议，并提出了资源所有者密码流程的建议。在IEFT 草案中，据说不得使用它，而Auth0 的文档指出，一般不建议使用它，但如果鼓励的流程不可用，则可行。
不得使用授予的资源所有者密码凭据。此授权类型不安全地将资源所有者的凭据公开给客户端。
尽管我们不建议这样做，但高度信任的应用程序可以使用资源所有者密码流...，它要求用户提供凭据...
虽然很明显人们不太喜欢 ROP 流程，但在某种条件下“绝对不能”和“应该”之间仍然存在相当多的中间立场。如果无法实现身份验证代码交换流程（如我们的场景），则仍然需要选择一些内容。
在我们的案例中，团队决定跳过 ROP 流程并使用客户端凭证流程，将其作为更安全的替代方案。我不明白这是怎么回事，因为客户端现在将根据其 ID 和秘密公开所有好东西，而在 ROP 流程中，还需要发送用户名和密码。
资源所有者密码凭证 (ROPC) 流程基本上从一开始就已被弃用，因为它违背了 OAuth 2 的主要目的之一，即不向客户端泄露最终用户凭证。您所指的草案预计将被纳入 OAuth 2.1，这是该规范的修订版，这将使其成为不得基于 OAuth 2.0 部署十多年的经验的版本。
理由：如果您确实想在应用程序中嵌入直接用户名/密码身份验证，则没有理由使用 OAuth 2.x。只需使用基本授权、LDAP 或其他一些现有方式将用户名/密码从应用程序呈现到后端即可。OAuth 工作组事后认识到，将 ROPC 合并到 OAuth 2 中是一个错误，因为它违背了 OAuth 的目的，造成了混乱，并且与现有替代方案相比没有任何好处，因此不得在修订版中使用。
客户端凭证 (CC) 流程解决了 OAuth 2.0 本质上不同的用例，不涉及资源所有者或最终用户。如果以某种方式使用 CC 流来实现 ROPC 用例，那就是对协议的严重滥用，其意图会导致与 ROPC 相同的问题。