沈海波

(广东第二师范学院 计算机科学系， 广东 广州 510303)



基于OAuth 2.0扩展的访问控制委托架构

沈海波

(广东第二师范学院 计算机科学系， 广东 广州 510303)

摘要:访问控制是保障网络资源安全访问的关键措施，而访问权限委托是取得动态而又灵活的访问控制的重要机制.OAuth 2.0规范给出一个开放的委托授权架构，并得到广泛应用，但不适用于需要更强安全特性的场合.通过对OAuth 2.0进行扩展，提出一种Web应用环境下的访问控制委托架构.在该架构中，利用委托令牌表示委托、访问令牌表示授权，可解决安全的委托访问问题；利用所有权证明(Proof-of-Possession，PoP)安全机制，可解决客户端认证到资源服务器的问题；讨论多步委托、委托的撤销和令牌与消息的保护机制等，可增强架构的灵活性和安全性.

关键词:OAuth 2.0；委托； 访问控制； 所有权证明；认证

0引言

今天的计算机系统或Web应用，大多是分布式的且具有动态特性，用户事先并不知道为了完成某一任务所应具有的权限.在这种情况下，委托可提供有效的解决方法，特别是在跨域的访问应用场合.委托(Delegation)是指委托者(Delegator)将自己的全部或部分对某些资源的操作权限授予给受托者(Delegatee)，让受托者代表委托者自己实现对资源或服务的操作[1].委托机制可增加访问控制的动态性、灵活性和规模性.委托可在单个安全域或跨多个安全域中实现，跨域时涉及到域联盟问题；委托通常涉及到委托的表达、委托的管理(如委托权限的撤销)等相关问题[2-3]. 文献[2]采用的是基于角色的委托与撤销机制，文献[3]采用的是属性的委托与撤销机制，并没有采用新近流行的委托授权架构OAuth(OpenAuthorization) 2.0[4-5]，两种方法在多域情况下需要进行角色映射和属性映射，在不同域间存在互操作问题[6].

OAuth2.0可以让资源拥有者委托第三方客户端代表自己，方便实现对托管在资源服务器上受保护的HTTP资源的访问，当然这首先需要获得授权服务器的授权许可，获取访问令牌.但OAuth2.0目前提供的是基于不记名令牌(BearerToken)[7]的访问机制，允许持有不记名访问令牌的实体访问相关的被保护资源，它不需要持牌人证明其拥有相应的密码学密钥(不需要验证持牌人的身份，即不进行所有权证明)，因此面临各种各样的威胁[8]，但文献[8]并没有给出解决相应威胁的具体方法；OAuth2.0的核心规范也没有定义客户端与资源服务器的安全交互(相互认证)机制，更没有委托授权的详细处理过程，需要开发方设计相关的安全机制和实现方法.为解决上述问题，本文提出了一个基于OAuth2.0扩展的Web应用环境下单个安全域中的访问控制委托架构.该架构利用基于通用的JWT(JSONWebToken)[9]格式的委托令牌表示权限委托，用基于JWT格式的访问令牌表示授权，解决安全的委托访问问题；利用所有权证明(Proof-of-Possession，PoP)安全机制[10-11]对OAuth2.0进行扩展，解决客户端认证到资源服务器的问题.本文还详细讨论了多步委托、委托的撤销和令牌与消息的保护等问题，以增强架构的灵活性和安全性.

1基于OAuth 2.0扩展的访问控制委托架构

1.1架构实体与功能

本文所提出的系统总体架构如图1所示.

图1　总体架构图

架构中涉及到的实体角色及其功能如下：

1)委托者：是资源拥有者 (ResourceOwner，RO)，一般指端用户，它将其拥有的资源操作权限授予给受托者，负责为受托者颁发委托令牌；另外，委托者还负责制定资源的访问控制策略.

2)受托者：是客户端(Client，C) ，如网站站点、Web应用、移动应用等，它接受委托者的委托并代表委托者对资源进行委托的操作.

3)授权服务器(AuthorizationServer，AS)：负责根据访问控制策略验证受托者的访问令牌请求并为受托者颁发PoP访问令牌.

4)资源服务器(ResourceServer，RS) ：负责托管受保护的资源，能够接收和响应使用访问令牌对受保护资源操作的请求.

根据委托访问的性质，需要委托者与受托者之间、授权服务器与资源拥有者之间、授权服务器与资源服务器之间都具有相互信任关系.因此本文假定它们三对实体之间互相拥有对方的公钥，表示这种信任关系.信任关系的具体建立方式不在本文讨论范围内.

另外，由于申请访问令牌时，AS需要对请求者进行身份验证，因此本文约定所有的客户端(受托者)均在AS处进行了注册认证，获取自己唯一的标识符client_id、私钥client_secret和完整的重定向URI(redirect_uri) ，作为客户端注册认证的凭据.

1.2访问控制委托实施流程

基于OAuth2.0的访问控制委托实施流程如图2所示.

图2　访问控制委托流程图

图2中所示的抽象的OAuth2.0委托访问流程描述了四种角色之间的交互，包括以下步骤：

1)受托者从委托者处请求委托授权.

2)委托者对委托请求进行验证后，为受托者颁发委托令牌(这是一个代表委托者的委托授权凭据).为了保证委托令牌的机密性和完整性，委托者可用受托者的公钥对委托令牌进行加密，并用自己的私钥对委托令牌进行签名.

3)受托者收到响应后解密出委托令牌，然后认证到AS(利用注册时返回的客户端凭据)并出示签名的委托令牌，以请求访问令牌.

4)AS验证受托者的身份(验证客户端凭据)并验证委托令牌(对委托令牌进行签名验证)，若有效则颁发访问令牌(本文颁发的不是不记名令牌，而是一种PoP令牌)，并为受托者与资源服务器创建一个共享会话密钥，而且将此密钥绑定到PoP令牌(绑定方法见1.4节)，最后访问令牌由AS签名.同时，也可选择性地颁发刷新令牌.另外，为了实现对令牌的管理，可在AS上分别建立委托令牌列表、访问令牌列表、刷新令牌列表.

5)受托者向RS请求受保护的资源，并出示PoP访问令牌以认证自己.认证方法见1.5节.

6)RS验证访问令牌(对令牌的AS签名、有效期、操作的资源及权限等进行验证)，若有效则给予请求的资源.

1.3委托令牌的结构

OAuth2.0规范中并没有定义令牌的表示方式，本文的各种令牌均采用比较简单紧凑的JWT结构[9,12]表示.委托令牌中包括如下主要的声明，也可根据需要添加其他声明元素.

delegatorID：委托者标识符;delegateeID：受托者标识符;scope：受托者要访问的资源，用URI表示;act(Action)：表示访问请求的资源操作选项，可以取值GET、POST、PUT、DELETE中的任一个，分别用对应的整数值0，4，2，3表示;exp(ExpirationTime)：有效期，表示自令牌发布之时起在这一时间段内有效;iat(IssuedAt)：令牌发布的时间；有效期与发布时间均用UTC格式表示;nonce：一次性随机数，既用于唯一标识委托令牌，又用于重放保护.

委托令牌样例如图3所示.

图3　委托令牌样例图

1.4PoP密钥和PoP访问令牌的绑定

基于PoP安全机制的受托者认证方案的关键，是如何将PoP密钥绑定到PoP令牌，作为所有权证明的凭据.本文的PoP令牌，其声明元素除了普通访问令牌所拥有的发布者iss、许可访问的资源scope、令牌主体sub(对应委托令牌的delegateeID)、颁布时间iat、有效期exp、许可对资源进行的操作act、一次性随机数nonce等常规声明元素外，通过专门定义一个cnf(comfirmation)声明元素，来实现PoP密钥到PoP令牌的绑定.cnf声明的值是一个JSON对象，其成员jwk(没有加密的PoP密钥)或jwe(经过加密的PoP密钥)用于标识PoP密钥，从而实现PoP密钥与PoP令牌的绑定，PoP密钥用JWK(JSONWebKey)[13]格式表示.PoP令牌可用于令牌颁布者声明令牌持有者拥有此PoP密钥，只要能够让资源服务器从密码学上证实自己拥有此PoP密钥，受托者(客户端)就能证明自己是PoP令牌的合法持有者.一个具有绑定功能的JWT格式的PoP令牌样例如图4所示. 为了保证会话密钥的安全性，需要进行加密.样例中声明jwe表示的是对称会话密钥k：{“kty”:”oct”, “alg”:”HS256”, “k”:”ZoRSOrFzn_Fz…”}，利用加密算法{“alg”:”RSA-OAEP”, “enc”:”AES128CBC-HS256”}，经过JWE(JSONWebEncryption)[14]加密规则加密后的结果.

图4　PoP令牌样例图

1.5受托者到资源服务器的认证方案

在OAuth2.0的很多实际应用场合，为了安全访问，资源服务器RS不仅要验证访问令牌的有效性，还需要对客户端C进行身份认证，证实C就是访问令牌的合法持有者，才能许可访问资源.但在OAuth2.0核心规范中，并没有定义C认证到RS的机制，并且不需要对持有不记名令牌的客户端进行身份认证，存在各种各样的安全隐患.本文基于所有权证明(PoP)的安全机制，提出了C(本文指受托者)认证到RS的方案.PoP安全机制的基本思想是授权机构为请求方颁布PoP令牌，该令牌包含相关的认证数据，能用于请求者证明自己拥有某种所有权的凭据，服务器通过验证请求者是否确有此凭据来确认请求者的身份(不是直接认证请求者本身)，因此称作所有权证明认证方法.因此，本文的方案是：当受托者向授权服务器请求访问令牌时，授权服务器为受托者创建相应的PoP令牌以及可与此PoP令牌绑定的密钥(称作PoP密钥，它就是所有权证明的凭据)，此密钥可以是对称密钥，也可以是非对称密钥.当受托者向资源服务器RS请求访问资源时，受托者通过向RS证明它拥有与PoP令牌绑定的密钥，从而证明受托者就是PoP令牌的合法持有者.资源服务器RS接收到访问令牌时，通过验证受托者持有的密钥与访问令牌上的密钥是否匹配，来认证受托者的身份合法性.PoP密钥与PoP令牌的绑定方法见1.4节.一种基于对称会话PoP密钥的受托者认证到资源服务器的方案如图5所示.

图5　基于对称PoP密钥的认证过程图

1)受托者持委托令牌向AS请求PoP访问令牌，请求消息中包括受托者唯一标识符delegateeID、授权类型grant_type(PoP类型)、请求访问的资源scope及操作act等.

2)授权服务器AS对访问令牌请求验证通过后，为受托者和RS创建一个会话密钥KS(一种对称PoP密钥).为了保护会话密钥KS的安全，需要利用RS的公钥pkRS进行加密后置入到PoP令牌的cnf声明元素中，并且对PoP令牌签名以进行完整性保护；然后对会话密钥KS利用受托者的公钥加密后，与访问令牌一起，传递给受托者.这样受托者既拥有PoP令牌，又拥有对应的PoP密钥，并且PoP密钥被绑定到PoP令牌.AS产生的PoP令牌样式如1.4节所示.

3)当受托者接收到AS的响应消息后，抽取会话密钥KS；当受托者向资源服务器RS请求访问资源时，需要向RS证明自己也拥有会话密钥KS，这只要用会话密钥KS计算请求消息的摘要值MAC，随请求发送给RS.

4)当资源服务器RS接收到受托者的请求后，恢复访问令牌并验证它，利用私钥解密cnf中的密钥抽取KS，然后利用KS验证请求消息的摘要值MAC，验证通过则说明受托者提供(拥有)的会话密钥KS与访问令牌中KS相匹配，从而实现对受托者的认证.

1.6委托的撤销

委托权限的撤销是委托机制灵活性的重要体现.为了实现对委托的撤销，需要对授权服务器的功能进行扩展，让其能提供撤销服务.同时，资源服务器也要建立被撤销的访问令牌的列表，以避免被撤销访问令牌的再使用.委托的撤销，有两种方式来实现.一种是过期失效法，即当委托令牌过期后，授权服务器从列表中删除过期的委托令牌及其对应的访问令牌和刷新令牌.第二种是强制失效法，即当委托者想要收回委托权时，申请授权服务器撤销委托，从列表中删除申请撤销的委托令牌，及其对应的访问令牌和刷新令牌.第二种方法对应的委托撤销过程如图6所示.

图6　委托撤销过程图

首先，委托者向授权服务器HTTPPOST委托撤销请求，请求中包括申请撤销的委托令牌的委托者标识符delegatorID、受托者标识符delegateeID、令牌类型token_type等参数.为了确认申请来自于委托者，委托者需要对请求消息进行签名.当授权服务器收到撤销请求后，首先验证请求消息的签名，然后验证申请被撤销的委托令牌的确是颁发给申请中的受托者；验证通过后，以HTTP200方式响应撤销请求，从列表中删除申请撤销的委托令牌及其对应的访问令牌和刷新令牌，并通知资源服务器何种访问令牌已被撤销.如果授权服务器验证失败，以HTTP400方式响应撤销请求，包括参数unsupported_token_type(申请撤销的令牌类型错误，即不是delegation_token,access_token,refresh_token三种令牌之一)和invaild_token(申请撤销的令牌不存在).

1.7多步委托问题

在实际应用中，一个任务的完成可能需要多步委托才能实现.例如，小车的拥有者Bob，委托他的服务经理Dave进行小车维修，Dave需要进一步委托小车制造商维修服务公司，才能完成小车的维修任务，这涉及到再次委托，有的任务可能涉及更多的委托过程.多步委托涉及到最初的委托者(originaldelegator)、中间委托者(intermediatedelegator)、最后的受托者(finaldelegatee)、授权服务器、资源服务器等相关角色以及委托令牌链.中间委托者同时也是受托者.3步委托的授权过程如图7所示.

图7　多步委托授权示意图

从图7中可以看出，每步委托过程中由委托者给受托者颁发委托令牌并签名，最后整个委托令牌链传递到最后的受托者，由受托者递交给授权服务器，由授权服务器根据访问控制策略对整个委托令牌链进行授权评估，如果最终的受托者得到认证、每个委托令牌的签名得到验证、委托的资源操作权限与申请的操作权限匹配或在委托的权限内、没有超时，则颁发访问令牌.为了保证委托令牌链的验证通过，需要后一个委托令牌的权限是前一个委托令牌的权限的子集，并且后一个委托令牌的有效期小于等于前一个委托令牌的有效期.

在存在多步委托的授权架构中，最初的委托者和中间委托者都可请求撤销其委托的权限；授权服务器也可强制撤销其颁发的访问令牌，从而使相应的委托失效.因此，各种撤销机制不应该引起互操作问题.要注意的是，当由最初的委托者撤销某一委托时，则整个委托链将被撤销；当由中间的委托者撤销某一委托时，则委托链中仅从此开始的委托将被撤销，前面的委托仍然有效.例如，假设原始委托者A将对某资源的操作权限r委托给B，B又将其委托给C，则当A撤销对r的委托时，B和C都会失去权限r；而当B撤销对r的委托时，则只有C失去权限r.

2结束语

访问控制是保护资源的重要安全方法，它可以防止非法的主体进入受保护的网络资源；允许合法用户访问受保护的网络资源；防止合法的用户对受保护的网络资源进行非授权的访问.而委托可以增强访问控制的灵活性和动态性，使之更适用于当今动态的分布式应用中.OAuth2.0作为广受欢迎的开放授权架构，已广泛应用于Internet和Web应用中，但它目前主要应用于公开的客户端，对于安全性要求更高的场合，还存在各种各样的安全问题.本文对OAuth2.0进行扩展，提出的一种委托授权架构，主要应用于单个安全域中，研究了委托授权机制.接下来的工作，一是进一步研究多步委托的委托链的管理机制，二是研究如何实现跨多个联盟安全域的委托授权问题，使架构适用于更多的场合.

参考文献：

[1]PHAMQuan,REIDJasonFrederick,MCCULLAGHAdrian,etal.Onataxonomyofdelegation.Computers&Security[J]. 2010,29(5):565-579.

[2] 袁家斌, 魏利利, 曾青华. 面向移动终端的云计算跨域访问委托模型[J]. 软件学报, 2013, 24(3):564-574.

[3] 吴槟, 冯登国. 多域环境下基于属性的授权委托模型[J]. 软件学报, 2011, 22(7):1661-1675.

[4]HARDTDick.TheOAuth2.0authorizationframework[EB/OL]. (2012-10-11).[2015-12-03].http://www.rfc-editor.org/info/rfc6749.

[5] 时子庆,刘金兰,谭晓华. 基于OAuth2.0 的认证授权技术[J]. 计算机系统应用，2012, 21(3):260 264.

[6]GUSMEROLISergio,PICCIONSalvatore,ROTONDIDomenico.Acapability-basedsecurityapproachtomanageaccesscontrolintheInternetofThings[J].MathematicalandComputerModeling, 2013,58(5-6):1189-1205.

[7]JONESMichael,HARDTDick.TheOAuth2.0authorizationframework:bearertokenusage[EB/OL]. (2012-10-11).[2015-12-10].http://www.rfc-editor.org/info/rfc6750.

[8]LODDERSTEDTTorsten,MCGLOINMark,HUNTPhil.OAuth2.0threatmodelandsecurityconsiderations[EB/OL]. (2013-01-08).[2015-12-17].http://www.rfc-editor.org/info/rfc6819.

[9]JONESMichael,BRADLEYJohn,SAKIMURANat.JSONWebToken(JWT) [EB/OL]. (2015-05-15). [2015-12-25].http://www.rfc-editor.org/info/rfc7519.

[10]TALAVIYABharatkumar,SHROFFNamrate.ModelingandassessingOAuth2.0underPoP(ProofofPossession)forsecrecy[J].InternationalJournalofEngineeringDevelopmentandResearch, 2015,3(2):883-886.

[11]HUNTPhil,RICHERJustin,MILLSWilliam,etal.OAuth2.0Proof-of-Possession(PoP)securityarchitecture[EB/OL]. (2015-12-01).[2016-01-08].https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/.

[12]JONESMichael,CAMPBELLBrain,MORTIMOREChuck.JSONWebToken(JWT)profileforOAuth2.0clientauthenticationandauthorizationGrants[EB/OL]. (2015-05-16).[2016-01-29].http://www.rfc-editor.org/info/rfc7523.

[13]JONESMichael.JSONWebKey(JWK) [EB/OL]. (2015-05-16).[2016-02-16].http://www.rfc-editor.org/info/rfc7517.

[14]JONESMichael,HILDEBRANDJoe.JSONWebEncryption(JWE). (2015-05-16).[2016-02-23].http://www.rfc-editor.org/info/rfc7516.

收稿日期：2016-04-27

基金项目:广东第二师范学院教授科研专项基金资助项目(2014ARF24)

作者简介:沈海波，男,湖北孝感人，广东第二师范学院计算机科学系教授，博士.

中图分类号：TP309

文献标识码：A

文章编号：2095-3798(2016)03-0080-06

OAuth 2.0 Extensions Based AccessControlDelegationFramework

SHENHai-bo

(DepartmentofComputerScience,GuangdongUniversityofEducation,Guangzhou,Guangdong, 510303,P.R.China)

Abstract:The access control is the key measure which ensures the secure access of the Web resources, and the authority delegation is the important method to achieve dynamic and flexible access control mechanism. OAuth 2.0 specification defines an open delegation authorization framework and is used in a wide variety of applications, but it is not applicative to the scenarios that require stronger security properties. By extending the functionalities of the OAuth 2.0, an access control delegation framework for the Web application environment is proposed in this paper. In the proposed scheme, a delegation authorization problem can be solved by using the delegation token to express delegation and the access token to express authorization. And the issue of client authentication to resource server is handled based on the Proof-of-Possession (PoP) security mechanism. Finally, the multi-step delegation issues, the revocation of delegation, the protection methods of all kinds of tokens and request-response messages are discussed in detail. Those measures can strengthen the framework’s flexibility and security.

Key words:OAuth 2.0; delegation; access control; Proof-of-Possession (PoP); authentication