【问题标题】:About OAuth2 grant types关于 OAuth2 授权类型
【发布时间】:2018-10-10 10:36:03
【问题描述】:

我正在阅读一篇关于 OAuth2 的文章,https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2。让我感到困惑的是赠款类型。它说

授权码:与服务器端应用程序一起使用 隐式:与移动应用程序或 Web 应用程序(在用户设备上运行的应用程序)一起使用

那么服务器端应用程序和 Web 应用程序之间的区别是什么,它们不一样吗?谁能给我一个例子,什么时候使用这两种授权类型?谢谢。

【问题讨论】:

    标签: security oauth-2.0


    【解决方案1】:

    您可以将每个 OAuth 授权类型视为一个流程。在 OAuth2 中有 4 种不同的授权类型。

    每个授权类型都相似,因为每个都有两个主要部分:

    1. 应用从用户那里获取授权密钥/访问令牌
    2. 应用程序使用密钥/访问令牌代表用户执行操作(例如,每天下午 12 点在 Tweeter 上发帖)

    要了解所有 4 种 OAuth2 授权类型之间的区别,让我们看一张并排比较它们的图片。

    图片来源:https://blog.oauth.io/understand-oauth2-grant-types-by-spotting-the-difference/

    授权码(右上角):

    • 共有 5 方:User、App、Guard、OAuth Server(表示为具有多个 key 的 keychain)、Resource Server(表示为具有多个门的 store)
    • 用户通过提供用户名/密码从OAuth Server获取Key/Access Token,并“移交”给Guard(后端),而App(前端)只能通过Guard访问Resource Server,因为它无权访问密钥
    • Guard 通过常规方式(例如,通过浏览器 HTTP 会话)识别应用程序的用户。

    隐式(右下角):

    • 只有 4 方,即没有 Guard(后端)
    • 用户通过提供用户名/密码从 OAuth 服务器获取密钥,并“移交”给应用程序(前端),因为没有 Guard
    • App因为有Key所以直接访问Resource Server

    注意事项:

    • 在隐式授权类型中,密钥位于前端(浏览器)中,它会暴露于更多的攻击向量,因此与密钥位于后端的授权代码授权类型相比,它的安全性较低

    有了这些理解,您现在可以回答自己的问题了:

    服务器端应用程序和网络应用程序之间有什么区别,它们不一样吗?

    服务器端应用程序有一个后端在前端和数据存储等之间进行中介,因此它们可以实现授权码授权类型,后端充当Guard,这样更安全。对于没有/不依赖后端的 Web 应用(单页应用),它们需要使用隐式授权类型。

    【讨论】:

      【解决方案2】:

      它是安全的,所以它很复杂。好吧,不要太复杂。

      首先,您需要确定您的 OAuth 客户端(即您的应用程序)是否为“Public or Confidential

      最好的规则是遵循RFC 6749 Section 1.3.2 “隐性赠款提高了一些人的响应能力和效率 客户端(例如作为浏览器内应用程序实现的客户端), 因为它减少了获得 访问令牌。但是,应该权衡这种便利性 使用隐式授权的安全隐患,例如那些 在第 10.3 节和第 10.16 节中描述,尤其是当 授权码授权类型可用。”

      【讨论】:

        【解决方案3】:

        我喜欢将授权视为一种东西,比如一枚硬币,而访问令牌则是另一种东西,一把打开门的钥匙。

        为了得到钥匙,你必须交出一枚硬币。接受什么样的硬币?

        好吧,你可以交出一个写有密码的硬币。这表明您知道密码,因此硬币被接受并且您获得了密钥。这是资源所有者密码凭据授权。

        网络服务器可以建立一个登录表单,用户输入一个网络服务器看到的密码。 Web 服务器使用密码获取密钥。

        除了密钥,您还可能获得了一个刷新令牌。所以稍后,你可以交出一个印有刷新令牌的硬币。这枚硬币被接受,你得到一个新的钥匙。这是刷新令牌授权。

        您可能不知道自己的密码。您的父母会为您记录您的密码。你让你的父母去为你取一个“代码”。他们与当局交谈并提供密码,并收到他们提供给您的代码。现在您可以将代码放在硬币上,交出硬币,然后收到钥匙。你没有看到密码,你的父母也没有看到钥匙。这是授权码授予。

        网络服务器要求您“使用 Google 登录”。谷歌会询问您的密码并给您一个授权代码,该代码会传回网络服务器。网络服务器无需查看您的密码即可从 Google 获取密钥。

        你可能与当局有特殊关系,并且拥有一个秘密。您不需要密码。在这种情况下,你可以把这个秘密放在硬币上,然后用它交换钥匙。这是客户端凭据授权。

        您可能是后端服务器,需要密钥,但没有用户名或密码。你只需要一个秘密来获取密钥。

        如果您是 VIP,您甚至不需要硬币!您只需挥动双手,即可获得钥匙。这是一个“隐含”的硬币——也就是说,没有硬币!这是隐式授权。

        你可能是一个手机应用程序,你真的没有安全的地方可以保密,所以你只需挥手就可以拿到你的钥匙。

        【讨论】:

          【解决方案4】:

          授权码授予提供了额外的安全性,并且适用于提供服务器会话的应用程序。通过分离用户代理和客户端来提供额外的安全性。例如。网络浏览器(用户代理)在 Stackexchange(客户端)上使用 Facebook 帐户登录。由于客户端 Web 应用程序(服务器)可以安全地获取访问令牌并存储它,因此令牌被泄露的风险较小。

          隐式代码授权不太安全,并且只有在没有 Web 服务器或没有服务器会话(例如本机移动应用程序、javascript 应用程序)时才会选择。由于用户代理必须获取令牌,因此拥有中间凭证(例如授权代码)并稍后获取访问令牌是没有意义的。

          这可能有助于https://oauth2.thephpleague.com/authorization-server/which-grant/

          【讨论】:

            猜你喜欢
            • 2021-04-24
            • 1970-01-01
            • 2018-11-04
            • 2018-05-26
            • 1970-01-01
            • 1970-01-01
            • 2017-02-23
            • 2019-05-02
            • 1970-01-01
            相关资源
            最近更新 更多