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

Question

We have a number of Web API 2.0 REST APIs, all of which are available over https, that are used by a small number of our customers. 对 API 的访问受到 IP 地址的限制，即他们向我们提供客户 IP 以同意我们的 T&C。 在设计 API 时，我们审查了 OAuth 2.0，并决定实施资源所有者密码凭证 (ROPC) 授权。 它被认为是最合适的。 在调用我们的“/token”端点时，使用他们的用户名和密码，凭据被验证，并被授予授权。 一个访问令牌发出三个小时。 与资源关联的客户端 ID 和机密在任何时候都不会暴露给客户端。 客户端将访问令牌附加到他们向其余端点发出的请求的 header。

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

Answer 1

你的目标应该是走上标准的道路，避免非标准的选择。 答案取决于以下问题：

问题

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

技术解答

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

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

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