【问题标题】:OAuth 2.0 Authorization Server and Access TokensOAuth 2.0 授权服务器和访问令牌
【发布时间】:2015-12-19 22:45:52
【问题描述】:

我目前正在研究 OAuth 2.0 和 OpenID Connect,但我对授权服务器和访问令牌有疑问。该规范将授权服务器定义为:

服务器在成功验证资源所有者并获得授权后向客户端颁发访问令牌。

据我了解,客户端将用户重定向到授权服务器,用户在授权服务器上进行身份验证,授权服务器向客户端发出访问令牌。

现在出现了一件我直到现在都无法理解的事情。有两种可能的方法可以理解这一点,我正在尝试找到正确的方法:

  1. 授权服务器颁发包含用户声明的访问令牌。带有用户声明的访问令牌随每个请求一起发送到资源服务器,资源服务器能够读取这些声明,然后允许或拒绝对资源的访问。

  2. 授权服务器发出已包含明确指令的访问令牌,以允许或拒绝访问资源服务器上的资源。资源服务器因此只是读取这些信息来查看用户是否可以做某事。

第一个选项似乎是理解事物的正确方法。在这种情况下,授权服务器将管理用户的声明并发布仅包含声明(如生日、年龄、角色等)的令牌。这反过来又赋予了资源服务器另一个责任:根据声明决定资源是否可用。

第二个选项更有限。授权服务器不仅需要发布声明,还需要为每个资源发布授权,并且令牌可能会变得非常繁重,并且管理这种复杂性似乎很困难。

所以我的理解正确吗?因此,授权负责管理用户声明并发布仅包含声明的令牌?另一方面,资源服务器负责根据声明是否允许访问资源?

【问题讨论】:

    标签: security authentication oauth-2.0 openid-connect


    【解决方案1】:

    访问令牌不包含用户的声明,但 ID token 包含。

    授权服务器负责管理访问令牌,但不一定必须管理用户的声明。应该有一个单独的服务器来管理用户的声明。

    没有。 2 听起来很奇怪,因为访问令牌的存在意味着“授权已被授予”。

    OAuth 2.0 (RFC 6749) 是授权的规范。 OpenID Connect身份验证的规范。不要混淆。

    【讨论】:

    • 感谢@TakahikoKawasaki 的回答。我只漏掉了一点。据我所知,对资源的授权应该基于检查用户声明的业务规则来完成。如果访问令牌不包含用户的声明,它真正包含什么?我的意思是,我们必须为每个单独的资源询问授权服务器,并且访问令牌包含允许每个单独资源的信息?
    • 基于声明的检查和基于scopes(权限)的检查是不同的。前者是基于角色(=用户属性)的访问控制。后者是基于访问令牌(= 用户授予的权限)的访问控制。如果您想根据角色保护您的 Web API,则不需要访问令牌。
    • 一般来说,访问令牌与“谁(用户)授予谁(客户端应用程序)什么权限(范围)”的信息相关联,它与用户声明无关。 RFC 7662 是获取有关访问令牌信息的规范。该规范通常显示了与访问令牌相关联的信息。
    • 那么当我们使用 OAuth 时,授权不是对用户而是对客户端应用程序?那么我们不应该使用OAuth来授权某个用户访问某个资源,而只是授权某个客户端应用以该用户的名义访问某个资源?
    • 你的理解是正确的。两者都称为“授权”。请注意,您可以同时使用两种访问控制机制(基于角色和基于令牌)。仅供参考:很好读:Resource-Based Access Control(作者 Stormpath),Understanding Permissions in Apache Shiro
    猜你喜欢
    • 2014-07-09
    • 2013-10-05
    • 2018-09-30
    • 1970-01-01
    • 2015-01-15
    • 1970-01-01
    • 2016-08-12
    • 1970-01-01
    • 2015-04-01
    相关资源
    最近更新 更多