OAuth 2.0/2.1 - 资源所有者密码凭证授予替代方案

Question

我们有许多 Web API 2.0 REST API，所有这些 API 都可以通过 https 获得，供我们的少数客户使用。对 API 的访问受到 IP 地址的限制，即它们在同意我们的 T&C 时向我们提供客户端 IP。在设计 API 时，我们审查了 OAuth 2.0，并决定实施资源所有者密码凭证 (ROPC) 授权。它被认为是最合适的。在调用我们的“/token”端点时，使用他们的用户名和密码，凭据被验证，并被授予授权。一个访问令牌发出三个小时。与资源关联的客户端 ID 和机密在任何时候都不会暴露给客户端。客户端将访问令牌附加到它们向其余端点发出的请求的标头中。

在查看 OAuth 2.1 时，我们注意到 ROPC 授权已被省略。我们很高兴将 ROPC 替换为授权代码授予，很可能，但这需要一些时间来实施、测试等。我一直在与我的另一位前同事讨论这个问题，他的团队正在与我们相似的位置。他们将 ROPC 用于他们的 REST API，但他们没有被客户端 IP 锁定。他们也将替换 ROPC，但他们正在考虑在此期间更改将用户名和密码发送到其“/token”端点的方式。正在考虑 Base64 编码，其中凭据的格式如下“{username}-{password}”或类似。他们在实施这一点上有什么价值吗？他认为混淆用户名和密码是值得的。

Answer 1

您的目标应该是走标准路线，避免非标准选项。答案取决于以下问题：

问题

• 您有哪些类型的客户？
• 您使用的是授权服务器还是本地 OAuth？
• 您的利益相关者是否愿意为变更付费？

技术答案

• B2B 客户。使用客户端凭据授予。这很容易，将来您可以使客户端机密成为提供 Mutual TLS 的更强大的凭据。从 ROPC 进行技术迁移很容易。

• 用户界面客户端。这里的方向是授权代码流（PKCE）。但是，这有一个以推荐的方式进行 OAuth 的先决条件：使用授权服务器、集成库来处理复杂的消息等等。因此，技术迁移的成本可能要高得多。

至少值得了解流程，以便您可以提前计划。