【问题标题】:Combine oAuth 2.0 Client Credentials and Resource Owner Password Credentials Grant Types for API?结合 API 的 oAuth 2.0 客户端凭据和资源所有者密码凭据授予类型?
【发布时间】:2014-07-09 06:59:39
【问题描述】:

我们正在构建一个 REST API,供我们自己的移动应用以及其他应用使用。我们希望通过似乎符合 oAuths Client Credentials Grant 定义的 API 密钥来防止它被公开访问。

某些 API 端点,例如那些会修改用户资源的端点,需要对用户进行身份验证,这似乎符合 Resource Owner Password Credentials Grant 定义。

这个问题基本上总结了与下面链接的相同场景,但没有询问实际实现可能是什么样子的任何示例:

How to keep the client credentials confidential, while using OAuth2's Resource Owner Password Credentials grant type

这是一个很难提出的问题。我已经查看了尽可能多的类似问题,但似乎都没有真正回答以下问题:

这样的流程将如何运作?除了在某些端点上为用户请求/传递 access_token 之外,客户端是否会在每个请求中传递一个 API 密钥参数/标头?

就源代码(尤其是 ruby​​/rails)而言,在这个特定用例的野外是否有任何可公开访问的示例?

另外,我并不严格依赖 oAuth,因此请告诉我是否有其他安全且经过验证的方法可以执行相同类型的操作。

【问题讨论】:

  • 嗨,马克,我遇到了和你一样的问题。您链接到的问题得出结论“保护 API 免受滥用的最佳选择是实施某种使用监控”。您确实可以在每个响应中包含客户端密码,但不幸的是,任何人都可以查看您的应用程序并找到它。你有没有遇到过很好的解决方案?
  • 我有同样的问题,在我看来,oauth2 没有提供任何解决方案。 oauth2 草案不是针对移动本机客户端编写的,并且使用资源所有者密码凭据,您必须信任不使用 3rd 方客户端的用户。
  • @Rengers 并非如此,我倾向于同意 alex 的观点,即 oauth 并没有真正为这种特殊情况提供解决方案。似乎每个人都倾向于推出自己的解决方案。

标签: api rest authentication oauth


【解决方案1】:

这根本不可能,无论你想出什么技术,除非你能 100% 控制用户用来连接你的服务的设备。

如果有一个软件在用户的机器上运行,并且除了客户端凭据之外不需要其他任何东西来执行某些特权操作,那么是的,有人将能够弄清楚这些凭据是什么。

如果您担心恶意用户会做他们不允许做的事情,您只需将其放在用户名和密码(ish)系统后面,暗示资源所有者密码凭据(或者实际上最好是授权码授予)。

但是,如果您的移动应用程序只需要能够访问与创建它的设备上的数据特别相关的 API,并且不希望用户进行身份验证,那么您可以只为每台设备组成一个随机的用户名和密码并存储。

【讨论】:

    猜你喜欢
    • 2016-12-31
    • 2017-01-02
    • 2011-09-05
    • 1970-01-01
    • 1970-01-01
    • 2018-05-25
    • 2021-06-20
    • 2015-04-01
    • 2019-02-19
    相关资源
    最近更新 更多