【问题标题】:Should non-confidential client applications be allowed to use the OAuth 2.0 Client Credentials flow?是否应允许非机密客户端应用程序使用 OAuth 2.0 客户端凭据流?
【发布时间】:2021-12-09 19:42:00
【问题描述】:

根据 OAuth 2.0 授权框架,当通过Client Credentials Grant 流程获得授权时,它说: “客户端凭据授予类型必须仅由机密客户端使用。”

我已经使用门卫(Ruby on Rails gem)实现了 OAuth 2.0 提供程序 API。但是,由 OAuth 2.0 提供程序创建的非机密客户端应用程序能够仅使用具有其 client_id 的客户端凭据授予流程,即没有 client_secret。这是预期的行为吗?

我在寻求保护我的资源服务器 API 时遇到了这个问题,这样即使对于不需要最终用户进行自动化的公共端点,即当客户端是资源所有者时,客户端仍然需要提供访问令牌。

在此用例中,授权代码授予流程不相关,因为资源所有者不是最终用户,并且根据最新的 OAuth 2.0 安全建议,不建议使用隐式授予流程。在此基础上,我发现 Client Credentials Grant 流程是最相关的流程,但我想仔细检查它是否适合使用,即使 OAuth 2.0 框架规定它必须仅供机密客户使用。

【问题讨论】:

    标签: ruby-on-rails oauth-2.0 oauth doorkeeper


    【解决方案1】:

    client_credentials 授权只能由机密客户端使用,因为客户端需要存储机密。这是因为客户端需要将 client_id 和 client_secret 发送到授权服务器才能获得 Token。 我不知道 client_credentials 流只能与 client_id 一起使用的任何特殊方式。

    据我所知,门卫文档也没有提到这一点。

    但是当客户端需要保存机密时,我不会在非机密客户端中使用 client_credentials 流。而且我不会使用任何只发送其 client_id 而没有其他任何东西到 /token 端点来获取令牌的授权。

    【讨论】:

    • 感谢@kaankom 的回复。我可以确认门卫确实允许客户端凭据授予流程通过仅使用与 OAuth 2.0 框架不一致的 client_id 为非机密客户端工作。话虽如此,我仍然需要找到一个流程来保护不需要最终用户进行身份验证的端点。特别是当客户端应用程序是 SPA 或本机应用程序时。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2014-12-27
    • 1970-01-01
    • 1970-01-01
    • 2019-12-04
    • 2022-06-16
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多