我们有许多 Web API 2.0 REST API，所有这些 API 都可通过 https 获取，供少数客户使用。对 API 的访问受 IP 地址限制，即它们在同意我们的条款和条件后向我们提供客户端 IP。在设计 API 时，我们审查了 OAuth 2.0，并决定实施资源所有者密码凭证 (ROPC) 授权。它被认为是最合适的。在调用我们的“/token”端点时，使用他们的用户名和密码，对凭据进行身份验证，并授予授权。访问令牌发出三个小时。与资源关联的客户端 ID 和机密在任何时候都不会暴露给客户端。客户端将访问令牌附加到它们向其余端点发出的请求的标头中。
在审核 OAuth 2.1 时，我们注意到 ROPC 授权已被省略。我们很高兴用授权代码授予替换 ROPC，很可能，但这需要一些时间来实施、测试等。我一直在与我的另一位前同事讨论这个问题，他的团队正在与我们相似的立场。他们将 ROPC 用于他们的 REST API，但他们没有被客户端 IP 锁定。他们也将替换 ROPC，但他们正在考虑在此期间更改将用户名和密码发送到其“/令牌”端点的方式。正在考虑 Base64 编码，其中凭据的格式如下“{username}-{password}”，或类似格式。他们在实施这个方面有什么价值吗？他认为混淆用户名和密码是值得的。
答案 0 :(得分：0)
您的目标应该是走标准的道路，避免非标准的选择。答案取决于以下问题：
问题
技术解答
B2B 客户。使用客户端凭据授予。这很容易，将来您可以使客户端机密成为提供相互 TLS 的更强大的凭据。从 ROPC 进行技术迁移很容易。
用户界面客户端。这里的方向是授权代码流 (PKCE)。但是，这有一个以推荐方式进行 OAuth 的先决条件：使用授权服务器、集成库来处理复杂消息等。因此，技术迁移的成本可能要高得多。
至少值得了解流程，以便您可以提前计划。