OAuth 2.0/2.1 -资源所有者密码凭据授权替代方案
OAuth 2.0/2.1 -资源所有者密码凭据授权替代方案
提问于 2021-03-24 04:23:02
我们有许多Web API 2.0 REST API，所有这些API都可以通过https获得，我们的一小部分客户使用这些API。对API的访问受IP地址的限制，即它们在与我们的T&C达成一致后向我们提供客户端IP。在设计API时，我们回顾了ROPC2.0，并决定实现资源所有者密码凭证( OAuth )授权。它被认为是最合适的。在调用我们的'/token‘端点时，使用它们的用户名和密码对凭据进行身份验证，并授予授权。颁发访问令牌的时间为三个小时。与资源相关联的客户端id和秘密在任何时候都不会暴露给客户端。客户端将访问令牌附加到它们向其余端点发出的请求的头部。
在回顾ROPC2.1时，我们注意到OAuth的拨款被省略了。我们很乐意将ROPC替换为Authorization Code Grant，但这将需要一些时间来实现、测试等。我一直在与我的另一位前同事讨论这个问题，他的团队与我们处于类似的位置。他们将ROPC用于REST API，但不受客户端IP的限制。他们也将取代ROPC，但他们正在考虑在过渡期间改变用户名和密码发送到他们的'/token‘端点的方式。他们正在考虑Base64编码，其中凭据的格式如下‘{用户名}-{密码}’，或类似。他们在实现这一点上有什么价值吗？他辩称，对用户名和密码的混淆使其变得值得。
回答 1
Stack Overflow用户
发布于 2021-03-25 03:52:57
你的目标应该是走一条标准的道路，避免非标准的选项。答案取决于这些问题：
问题
- 您有哪些类型的客户端？
- 您使用的是授权服务器还是自行开发的OAuth？
- 您的利益相关者是否乐于为更改付费？
技术答案
- B2B客户端。使用客户端凭据授予。这非常简单，将来您可以使客户端秘密成为一个更强的凭据，提供相互TLS。从ROPC进行技术迁移很容易。
- UI客户端。这里的方向是授权码流(PKCE)。但是，这需要以推荐的方式进行OAuth :使用授权服务器、集成库来处理复杂的消息等。因此，技术迁移的成本可能要高得多。
至少，了解流程是值得的，这样您就可以提前计划。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/66770779
复制相关文章
相似问题
腾讯云开发者
