【问题标题】:What are the limits of public clients in OAuth 2.0OAuth 2.0 中公共客户端的限制是什么
【发布时间】:2017-09-02 20:11:20
【问题描述】:

OAuth 2.0 指定了两个client types

  • 公开 (client_id)
  • 机密 (client_id:client_secret)

第 2.2 节说:

客户端标识符不是 秘密;它向资源所有者公开,不得使用 单独用于客户端身份验证。

虽然我很清楚公共客户端主要用于隐式流程,但这比看起来的要多。在执行身份验证代码流时,我们首先使用我们的 client_id 请求授权端点,不需要秘密。然后,在得到用户的同意和授权码后,我们request the token endpoint。根据规范,我们可以在没有 client_secret 的情况下请求这个端点:

client_id
     REQUIRED, if the client is not authenticating with the
     authorization server as described in Section 3.2.1.

如果客户类型是保密的或客户是发给客户的 凭据(或分配的其他身份验证要求), 客户端必须按照所述向授权服务器进行身份验证 在第 3.2.1 节中。

...

授权服务器必须:

...
o ensure that the authorization code was issued to the authenticated
  confidential client, or if the client is public, ensure that the
  code was issued to "client_id" in the request,

所以基本上本节说我们能够在没有客户端密码的情况下请求这个端点。现在,除了那些可能包含在请求中的刷新令牌之外,它没有说明任何关于刷新令牌的内容。

Refreshing an access token 提及:

因为刷新令牌通常是用于 请求额外的访问令牌,刷新令牌绑定到 发给它的客户。如果客户类型是机密的或 客户端获得了客户端凭据(或分配了其他 身份验证要求),客户端必须与 授权服务器,如第 3.2.1 节所述。

所以基本上我们可以在没有客户端身份验证的情况下刷新访问令牌。

现在,让我感到困惑的是implicit flow 不允许发布刷新令牌:

授权服务器不得发出刷新令牌。

它没有明确说明为什么我们不能这样做,只是说我们不允许这样做。我的理由是这是不允许的,因为客户端不能被信任。但是既然公共客户端允许授权代码流,为什么我们实际上需要隐式流,如果公共客户端可以实现同样的事情,再加上获取刷新令牌?

如果有人能澄清这一点,我会很高兴。

【问题讨论】:

    标签: oauth oauth-2.0


    【解决方案1】:

    您可以在没有客户端密码的情况下请求/刷新访问令牌,风险自负。或者我们可以说这取决于您的安全要求。该规范仅阐明了机密客户端的客户端身份验证,基本上是在客户端是机密的情况下。它必须由服务器进行身份验证。

    对于公共客户,规范说:

    授权服务器不得发布客户端密码或其他 本地应用程序或基于用户代理的客户端凭据 用于客户端身份验证的应用程序客户端。

    因此,公共客户端甚至没有要验证的秘密。然后规范还说:

    当无法进行客户端认证时,授权服务器 应该采用其他方式来验证客户的身份——对于 例如,通过要求注册客户端重定向 URI 或争取资源所有者确认身份。一个有效的 重定向 URI 不足以验证客户端的身份 在请求资源所有者授权时,但可用于 防止在之后向假冒客户提供凭据 获得资源所有者授权。

    你也可以看看PKCE

    回到你的问题,我认为你误解了:

    根据规范,我们可以在没有 client_secret 的情况下请求此端点。

    不太对,您必须对机密客户端进行身份验证,并且您不能使用客户端密码(它没有)对公共客户端进行身份验证。

    授权服务器不得发出刷新令牌。

    我认为这完全是安全问题。在隐式授权中,我们是在一个可能不安全的环境下运作的。公开刷新令牌可能会损害您的系统,因为我们已经在这种授权类型中公开了访问令牌(请阅读security consideration for access token)。

    但是既然公共客户端允许授权代码流,为什么我们实际上需要隐式流,如果公共客户端可以实现同样的事情,再加上获取刷新令牌?

    它们适用于完全不同的用例。来自https://oauth.net/2/grant-types/implicit/

    隐式授权类型是一个可供公共客户端使用的简化流程,其中访问令牌会立即返回,而无需额外的授权代码交换步骤。

    一般不推荐使用隐式流(有些服务器完全禁止这种流)。自最初编写规范以来,行业最佳实践已更改为建议公共客户端应改为使用带有 PKCE 扩展的授权代码流。

    最后,我建议您与this site 一起玩,以更好地了解不同的资助类型。

    【讨论】:

    猜你喜欢
    • 2016-11-05
    • 2015-08-22
    • 1970-01-01
    • 2018-09-06
    • 2017-10-18
    • 2023-03-17
    • 1970-01-01
    • 2015-01-14
    • 2013-11-06
    相关资源
    最近更新 更多