基于OAuth2.0, OpenID Connect和UMA的用户认证授权系统架构

沈 桐，王 勇，刘俊艳

（北京汇通金财信息科技有限公司，北京 100053）

基于OAuth2.0, OpenID Connect和UMA的用户认证授权系统架构

沈 桐，王 勇，刘俊艳

（北京汇通金财信息科技有限公司，北京 100053）

用户认证系统的基本功能是用来证明一个用户是他声称的那个用户，并管理该用户相关的基本信息。用户授权系统的基本功能是授予用户或应用权限访问受保护的资源。OAuth2.0是一个用户授权框架，该框架提供了使客户端应用可以请求用户授权该应用访问该用户受保护的资源的功能。OpenID Connect是基于OAuth2.0框架的用户身份认证协议。UMA是基于OAuth2.0框架的用户间授权协议。本文介绍了上述框架和协议的功能与实现，并整合三者尝试搭建完整的用户认证授权系统，使该系统架构具备功能上的完备性，良好的安全性，灵活的连通性，可扩展性，高性能以及高可用性。

用户认证；用户授权；OAuth2.0；OpenID Connect；UMA

0 用户认证授权简述

用户认证系统的解决的核心问题是“确定用户是他声称自己是的那个人”。用户授权系统解决的核心问题是“用户如何获取权限来访问受保护的资源”。用户认证不一定发生在用户授权之前，因为一个未认证的匿名用户也可能能够获取一定的受限制的权限。对网络应用来说，常见的用户认证系统的实现方式是用户使用用户名和密码在网络应用提供的页面进行登陆，网络应用把用户提供的信息与自身管理的用户数据库中的信息进行比对来进行认证。网络应用的数量的爆炸性增长催生了对单点登陆系统的需求。而常见的授权系统则包括应用A直接拿着用户的密码等信息、模仿用户访问应用B下受保护的资源。这种授权方式的弊端很多，包括用户密码等敏感信息的泄露风险，以及应用B无法区分应用A与用户自身究竟是谁在发起访问等。

1 OAuth2.0简述

OAuth2.0框架解决的基本问题是应用如何在不直接使用用户的账号密码等敏感信息、不模仿用户自身，就可以去获取访问受保护的资源的权限的问题[1]。OAuth2.0框架解决上述问题的思路是客户端通过授权服务器获取用户签发的访问令牌，并拿着访问令牌访问资源服务器下受保护的资源，资源服务器在核实令牌有效后允许客户端的访问。授权服务器签发的访问令牌的主流形式是Bearer Token[2]，该令牌自身不包含任何客户端和资源服务器可以解析的信息，也就是任何获得了Bearer Token的客户端均可通过该令牌访问对应的资源，因此基于OAuth2.0的授权系统的所有http请求均需通过TLS加密传输。OAuth2.0框架是单纯的用户授权框架，本身不提供用户认证功能，但可以基于OAuth2.0框架的授权体系去搭建用户认证系统。

图1 OAuth2.0组件视图Fig.1 OAuth2.0 component view

如图所示，OAuth2.0授权系统的基本组成部分为资源拥有者（用户），客户端应用，授权服务器和资源服务器四部分。一个典型的OAuth2.0授权流程是由客户端应用发起，将用户引导向授权服务器的授权接口，用户在授权服务器上登陆并授权客户端以访问资源服务器中受保护资源的权限，客户端从授权服务器获得访问令牌后持令牌访问资源服务器，资源服务器验证令牌有效[3]后返回正常的资源信息。OAuth2.0授权流程依据客户端性质不同有授权码流程，隐性流程，客户端账号密码流程，用户账号密码流程等，其中授权码流程最为典型，该流程具体时序图如图2所示。

2 OpenID Connect简述

OpenID Connect是基于 OAuth2.0框架的用户认证协议[4]。OpenID Connect解决的基本问题是允许客户端能够使用用户在授权服务器进行的身份认证作为自身系统的身份认证，以及允许客户端通过简单的 Restful风格的网络调用获取用户的基本信息。基于OpenID Connect的用户认证系统本质上是以 OAuth2.0授权服务器作为登陆点的单点登陆系统。基于OpenID Connect的用户认证系统组件视图如图3所示。

如图3所示，OpenID Connect用户认证系统的基本组成部分为用户，客户端应用，身份提供者三部分。其中用户与客户端应用完全对应OAuth2.0中的同名组件，而OAuth2.0框架中的授权服务器和资源服务器共同组成此处的身份提供者。基于OpenID Connect的用户认证系统的标准流程为用户尝试在客户端应用登陆，客户端应用将用户引导至身份提供者页面，用户在身份提供者登陆后授权客户端应用使用该用户的身份登陆，身份提供者将OAuth2.0访问令牌以及一个包含用户基本登陆信息的 JWT令牌[5]——ID Token返回给客户端，客户端解析ID Token并验证有效后认为用户在客户端登陆，并持令牌访问身份提供者获取用户的详细信息。具体流程时序图如图4所示。

3 UMA 简述

UMA的全称是User Managed Access，是基于OAuth2.0框架的用户间授权协议[6]。UMA协议解决的基本问题是用户与用户间的授权，并允许用户引入自定义的授权服务器。在OAuth2.0的基本组件之外，UMA协议引入了访问申请者（Requesting Party）这一新组件。在 UMA协议中，资源拥有者负责协调授权服务器与资源服务器的关系，而访问申请者则通过他所操作的客户端去尝试访问受保护的资源，即由资源拥有者授权访问申请者——很可能是不同的人——所掌控的客户端应用访问受保护的资源。通过允许用户引入自定义的授权服务器，使得用户可以完全掌控生态系统中哪些组件可以接触到他自己的各种数据。基于 UMA协议的授权系统的基本组件如图5所示。

图2 OAuth2.0授权码流程时序图Fig.2 Sequence Diagram of the Authorization Code Flow of OAuth2.0 Framework

图3 Op enID Connect组件视图Fig.3 OpenID Connect component view

图4 Op enID Connect用户登陆时序图Fig.4 User login sequence diagram of OpenID Connect

图5 UMA 组件视图Fig.5 UMA component view

如图5所示，UMA在OAuth2.0的基础上增加了访问申请者这一组件，资源拥有者不再直接与客户端应用发生联系，授权服务器作为整个系统的核心，既需要提供API给资源服务器用于资源注册、权限注册以及令牌解析服务，还需要提供 API给客户端用于访问申请者的校验和访问令牌的签发。在标准的UMA授权流程中，资源拥有者和访问申请者各自负责一般的流程。对资源拥有者来说，首先由资源拥有者提供给资源服务器一个授权服务器的地址，资源服务器在发现了授权服务器的配置信息后、向授权服务器注册自身，资源拥有者在授权服务器给资源服务器授权、允许其访问授权服务器提供的Protection API（包括资源注册、权限注册以及令牌解析服务），资源服务器得到 Protection API Token后持该Token向授权服务器注册资源集，最后资源拥有者在授权服务器上为注册的资源设置访问规则，此时资源拥有者在整个流程中需扮演的角色就基本结束了。对访问申请者来说，首先访问申请者引导客户端应用访问受保护的资源（此时客户端应用并没有足够的授权），资源服务器解析客户端的请求获得要访问的资源以及该资源对应的授权服务器后，向对应的授权服务器发起请求获得授权票，并将该授权票以及授权服务器的地址返回给客户端应用，客户端应用获取到授权服务器的地址后将自身注册到授权服务器，客户端应用再持授权票从授权服务器换取访问令牌，授权服务器根据授权票获得客户端想要访问的信息以及访问策略，如果客户端未提供访问策略所需的足够的声明信息，则授权服务器会告知客户端收集足够的声明信息后再申请访问令牌，客户端收集声明信息的常见方式有将访问申请者重定向到授权服务器的声明收集地址并由访问申请者在授权服务器登陆等，客户端重新提交包含了额外的声明信息的授权票后获得访问令牌，客户端应用持令牌访问资源服务器下的受保护的资源，资源服务器访问授权服务器的令牌解析地址判断令牌有效后，最后允许客户端访问受保护的资源。该流程的具体时序图如图6所示。

图6 UMA 授权流程时序图Fig.6 User authorization sequence diagram of UMA

4 整体功能设计

4.1 整体功能说明

基于OAuth2.0，OpenID Connect和UMA的用户认证授权系统，将整合三者的功能，实现以授权服务器为身份提供者的单点登陆系统，实现用户对客户端应用授权访问受保护的资源，以及实现用户对其他用户的客户端应用进行授权的功能。本架构设计未指定实现时使用的语言以及数据库的选型，即可以适用于各种语言和数据库实现。客户端和资源服务器在授权服务器的注册与管理既可以使用静态方式，也可以使用动态[7]方式。本架构使用 JWT作为令牌格式，并使用JWS[8]，JWE[9]和JWK[10]等配套技术保证JWT的安全。各组件关系图如图7所示。

图7 系统组件视图Fig.7 component view of system architecture

如图7所示，本系统由授权服务器，授权数据库，资源服务器，客户端应用，日志监控平台构成，本系统的使用者有资源拥有者以及访问申请者两类，特别的，如果资源拥有者和访问申请者为同一人，本系统会自适应为基本的OAuth2.0系统。访问申请者在客户端和授权服务器的登陆使用 OpenID Connect进行单点登陆。资源拥有者在资源服务器和授权服务器的登陆也可以使用OpenID Connect进行单点登陆。授权服务器进行集群部署，日志监控平台主要对授权服务器进行监控。授权数据库在授权服务器集群看来是单个节点的数据库，但数据库自身可以采用集群部署，前提是选用的数据库支持集群化。

4.2 安全性架构设计

基于 OAuth2.0框架的用户认证授权系统可能会有一些潜在的安全风险，本架构尝试从客户端、授权服务器、资源服务器及令牌四个方面对这些潜在的安全风险进行分析，并给出解决方案[11]。

OAuth2.0客户端安全架构首先要考虑的是基本安全问题，如客户端密码、授权码和访问令牌的保密。客户端密码的保密可以使用动态客户端注册，从而规避了在客户端持久化客户端密码及多客户端共享密码的问题。授权码、访问令牌需要注意不能出现在任何的日志中，以及选择不在客户端持久化授权码和访问令牌。客户端在授权码流程中的授权码请求中需要附上随机生成的state值，并在授权服务器返回授权码后校验随授权码返回的state值是否相同，从而规避 CSRF[12]攻击。在客户端向资源服务器发起请求时，需要将访问令牌放入Authorization Header中而不是请求参数中，降低令牌泄露的风险。客户端在授权服务器注册的回调地址需要尽可能精确，且如果一个客户端注册了多个授权服务器，则在各授权服务器上的回掉地址都必须唯一，以避免客户端密码的泄露。对原生应用客户端而言，可以使用Reverse DNS Notation来确定回调地址，减少回掉地址冲突的可能性[13]。为避免授权码被拦截，可以通过 PKCE[14]协议绑定授权码请求与访问令牌请求，确保两个请求由同一个客户端发起。

OAuth2.0资源服务器面对的首要安全风险是XSS[15]攻击，降低此攻击风险的措施首先是资源服务器不要支持除 Authorization Header之外的其他Token传递方式，然后是对请求返回结果的类型做具体的约束，并增加X-Content-Type-Options: nosniff和X-XSS-Protection: 1; mode=block两个header。另外为了支持隐式授权流中对资源服务器的调用，需要在资源服务器中增加 CORS[16,17]支持。最后由于OAuth2.0框架需要全程使用 https协议，在资源服务器中可以通过增加 HSTS header[18]来强制浏览器通过https协议与资源服务器交互。

OAuth2.0授权服务器是整个基于 OAuth2.0的用户认证授权系统的核心应用。授权服务器需要强制规定授权码只能使用一次，若多次使用同一个授权码，授权服务器必须拒绝并同时收回之前基于此授权码签发的所有访问令牌。授权服务器需要确保使用授权码请求访问令牌的客户端与当初请求授权码的客户端是同一个客户端。为了避免由回掉地址引起的安全风险，授权服务器应使用精确匹配的方式验证回调地址是否与配置的相同，并需要确定访问令牌请求的回掉地址与授权码请求的回掉地址相同。

授权令牌是基于 OAuth2.0的用户认证授权系统的核心信息载体。主流的授权令牌类型是 Bearer Token，即任何持有该令牌的客户端均可以调用该令牌允许的资源。对Bearer Token来说，其安全风险可以分类为令牌伪造，令牌重放，令牌重定向以及令牌信息泄露。由于Bearer Token的持有即可用的特点，Bearer Token的所有传输过程均必须使用点到点加密传输，如 TLS。在客户端请求令牌时，建议请求最小的可用scope，如果基于用户体验考虑不能过度限制scope，则可以通过使用更新令牌重新获取更小 scope的访问令牌。在客户端需要考虑令牌的安全保存，在没有必要性的前提下不使用持久化保存访问令牌。在授权服务器保存访问令牌时，可以保存该令牌的Hash值而不是令牌本身，并在签发访问令牌时，限制令牌的有效期限在一次完整的API调用时长为宜。授权服务器需要实现完备的日志监控系统，对令牌的请求、签发、使用、收回[19]时的上下文做详尽的记录，但需注意令牌本身不能出现在日志中。对资源服务器而言，一样需要注意在日志中不能出现访问令牌，在要求 scope时要求针对某个调用最低限的scope，考虑不把令牌保存在持久层，正确的验证令牌的可用性，以及限制对API调用的调用数量和频度从而避免DDOS攻击和避免攻击者反复猜测令牌。

由于本架构的授权服务器和资源服务器采用分布式架构，资源服务器与授权服务器无法做到数据库共享，因此在Bearer Token的基础上采用JWT向令牌的内容中注入相关的信息，使资源服务器可以对令牌做初步的解析，并使用JWS签名来确保令牌的内容不被篡改，以及使用JWE加密来确保令牌的内容不会泄露。签名和加密的算法均使用RS256非对称加密，其中JWS签名和JWE加密的加密方均为授权服务器，解密方均为资源服务器，区别在于JWS签名使用授权服务器自身的密钥，而JWE加密是使用资源服务器暴露的公钥。选择非对称加密而不是对称加密的主要原因是对称加密将使得资源服务器同样有能力独力生成访问令牌。在解析JWT进行初步验证的基础上，资源服务器依然需要调用授权服务器的令牌解析地址确认令牌的有效性以及查询相关的敏感信息。同时，客户端在必要时可以调用授权服务器的令牌回收地址主动回收授权令牌。

4.3 连通性及可扩展性架构设计

在基于OAuth2.0的用户认证授权系统中，授权服务器、资源服务器和客户端应用三者相互独立，但在实际系统中，授权服务器和资源服务器的角色可以集中在单个应用中。这种高度耦合的结构适用于资源量少的情况，以及资源服务器和授权服务器由同一方提供的情况。在本架构的目标应用场景中，资源服务器可能并不是由授权服务器的提供方提供，同时资源服务器的数量可能会非常多，使得授权服务器和资源服务器合二为一不再合适。在授权服务器和资源服务器分散部署的前提下，授权服务器需要管理大量的资源服务器，为它们设置大量的客户端id和客户端密码，这种管理方式随着资源服务器的增加而复杂度迅速增长。更进一步，部分资源服务器是由第三方提供，这类资源服务器在授权服务器上的注册如果采用静态方式，则无论是资源服务器的新增还是配置的变更都将成为维护上的难题。在 UMA协议下，授权服务器甚至可能会需要资源服务器去动态的发现，无法通过静态的方式进行配置。综上得出的结论是需要资源服务器的动态注册方案，通过用户选择或自动发现的方式动态配置授权服务器的信息后，再由资源服务器注册自身到授权服务器。这是UMA协议的通用解决方案。

同样的，客户端应用在数量上会更加庞大，同时客户端应用的提供者有更大的可能与授权服务器提供方不相同。同时客户端应用的安全特性决定了保存在客户端应用的常量有较大的泄露风险。为了使得客户端应用在管理上可控并增强客户端应用的安全性，客户端在授权服务器上的注册应当尽可能采用动态注册方案。

4.4 性能及高可用性架构设计

在基于OAuth2.0的用户认证授权系统中，资源服务器在收到客户端应用的请求后，需要在初步判断令牌有效后，调用授权服务器的令牌解析服务最终确定令牌的有效性。在默认的情况下，资源服务器每收到一个客户端请求，都会调用一次授权服务器的令牌解析服务。这在访问量巨大的情况下会带来无法忽视的性能负担。为了增强性能，资源服务器可以缓存令牌有效性信息，并在合适的时间点使缓存失效，从而在性能和安全性上取得平衡。

授权服务器作为基于 OAuth2.0的用户认证授权系统的核心，其可用性至关重要。为了保证授权服务器在绝大多数时间都可用，需要进行集群部署。在本架构中，多台授权服务器默认共享一个核心数据库，各授权服务器的一次功能调用在数据库端视为一个事务。由于授权服务器需要与用户进行前端的交互，有部分数据会保存在Session中，为了使多台授权服务器可以共同为同一个用户服务，各授权服务器之间需要设置Session共享。

5 结论

本文介绍了 OAuth2.0授权框架，OpenID Connect协议和 UMA协议，并详细说明了基于OAuth2.0，OpenID Connect和UMA的用户认证授权系统的架构设计。该架构设计解决了用户单点认证登陆，动态授权及用户间授权等问题。该架构设计满足了高度安全性，连通性，可扩展性，高性能及高可用性的架构设计目标，可以适用于广泛的应用场景。

[1] E Hammerlahav. The OAuth2.0 Protocol. tools.ietf.org.

[2] M Jones, D Hardt. The OAuth 2.0 Authorization Framework:Bearer Token Usage. Ietf Rfc, 2012.

[3] E J. Richer. OAuth 2.0 Token Introspection. tools.ietf.org.

[4] DN Sakimura, J Bradley, M Jones. OpenID Connect Standard 1.0-draft 21. m1.archiveorange.com.

[5] MD Chen, HS Zhu, B Wang, QF Wen, C Institute. JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants. 《British Journal of Urology》,2013 , 54(6): 641–644.

[6] MP Machulak, EL Maler, D Catalano, AV Moorsel. Usermanaged access to web resources. Workshop on Digital Identity Management, 2010: 35-44.

[7] J Bradley，M Machulak，M Jones，J Richer. OAuth 2.0 Core Dynamic Client Registration. 《Pm Engineer》, 2013.

[8] M Jones， J Bradley, N Sakimura. JSON Web Signature(JWS). rfc-editor.org.

[9] J Hildebrand. JSON Web Encryption (JWE). rfc-editor.org.

[10] MBJ &Lt, M Com&Gt. JSON Web Key (JWK). rfc-editor.org.

[11] K Curran, E Ferry, JO Raw. Security evaluation of the OAuth 2.0 framework. 《Information & Computer Security》, 2015,23(1): 73-101.

[12] R Feil，L Nyffenegger. Evolution of cross site request forgery attacks. 《Journal in Computer Virology》, 2008, 4(1): 61-71.

[13] W Denniss, J Bradley. OAuth 2.0 for Native Apps. rfc-editor.org.

[14] E N. Sakimura, J Bradley, N Agarwal. Proof Key for Code Exchange by OAuth Public Clients. rfc-editor.org.

[15] P Vogt, F Nentwich, N Jovanovic, E Kirda, C Krügel, etc.Cross Site Scripting Prevention with Dynamic Data Tainting and Static Analysis. Network & Distributed System Security Symposium , 2007.

[16] H Saiedian, SB Dan. Security Vulnerabilities in the Same-Origin Policy: Implications and Alternatives. 《Computer》, 2011, 44(9): 29-36.

[17] A Van Kesteren. Cross-Origin Resource Sharing. Betascript Publishing, 2010.

[18] H Netze. HTTP Strict Transport Security (HSTS). HTTP Strict Transport Security (HSTS) draft-hodges-strict-transport- sec-02, 2012.

[19] M Scurtescu. OAuth 2.0 Token Revocation. rfc-editor.org.

System Architecture for User Authentication and Authorization Based of OAuth2.0, OpenID Connect and UMA

SHEN Tong, WANG Yong, LIU Jun-yan
(Beijing huitong jincai information technology co., LTD., Beijing 100053, China)

The basic function of a user authentication system is to prove a user is who he claims to be, and to manage the user’s basic information. The basic function of a user authorization system is to give user or application allowance to access protected resources. OAuth2.0 is a user authorization framework that enables client application to ask users to delegate to them the ability to access the user’s protected resources. OpenID Connect is a user authentication protocol based on OAuth2.0 framework. UMA is an authorization protocol based on OAuth2.0 that enables user to user authorization. This paper gives a comprehensive overview of the functionality of the aforementioned frameworks and tries to build a complete user authentication and authorization system based on those frameworks. The finished system architecture is functionally complete, has good security, connectivity, extensibility,availability and high performance.

User authentication; User authorization; OAuth2.0; OpenID connect; UMA

TP393.08

A

10.3969/j.issn.1003-6970.2017.11.031

本文著录格式：沈桐，王勇，刘俊艳. 基于OAuth2.0, OpenID Connect和UMA的用户认证授权系统架构[J]. 软件，2017，38（11）：160-167

沈桐(1984-)，男，北京汇通金财信息科技有限公司，主要研究方向：互联网技术；王勇(1982-)，男，北京汇通金财信息科技有限公司，主要研究方向：互联网+电力营销服务，互联网技术；刘俊艳(1978-)，女，北京汇通金财信息科技有限公司，主要研究方向：计算机应用。