基于OAuth2.1的统一认证授权框架研究

郭晓宇 阮树骅,2

1(四川大学网络空间安全学院 成都 610207)

2(四川大学网络空间安全研究院 成都 610207)

(guoxiaoyu@stu.scu.edu.cn)

随着互联网的发展，企业中应用的开发模式从全部业务开发到一个应用中转变为将业务拆分为各类子应用，对每个子应用进行独立开发和运维，增强了系统的扩展性，同时在添加新应用时，也能保证不影响原有系统的运行，使系统维护更加方便，在更新的同时也不会影响到用户的使用.随着企业业务的不断发展，各类子应用不断增多，设计统一认证授权系统，为用户提供统一登录认证界面，不仅能够使用户拥有好的使用体验，同时也减轻了开发和运维工作人员对系统开发和运维的工作量.

当前环境下，开发认证授权系统除了不同企业内部存在不同的定制化需求外，还存在大量一致的基础需求(如认证方式、权限管理[1]、安全需求[2]等).因此，研究一个适用于企业内部且可扩展的统一认证授权框架，使开发人员能够基于该框架进行快速开发和设计，简化开发流程，缩短开发时间，具有实践指导意义和应用价值.

本文在对OAuth2.1(open authorization)协议解析的基础上，设计了一个适用于企业内部的统一认证授权框架.该框架在用户界面层、服务层和数据层3层架构的基础上构建，为用户单点登录、应用认证、OAuth2.1授权、用户和应用数据管理、权限管理以及安全风险检测等问题提供了解决方案.开发人员可以根据企业内部不同的应用场景，在本框架的指导下进行相应的开发，以实现符合企业需求且安全性较高的统一认证授权系统.

1 OAuth2.1协议规范

OAuth1.0正式版协议RFC 5849[3]最早于2010年4月发布，2012年10月发布OAuth2.0协议RFC 6749[4]，2.0版本发布后该协议被广泛应用于授权服务的开发，百度开放平台、腾讯、微博等各大网络平台都基于OAuth2.0协议开发了相应的授权服务.2021年3月OAuth2.1协议草案[5]发布.

OAuth协议是指服务器通过使用用户授权颁发的访问令牌对用户资源进行访问的协议，该协议能够防止用户的敏感信息(用户名/密码等)在传输过程中泄露，同时又能保证服务器访问到用户的资源.OAuth2.1协议定义了4个关键的角色，分别是资源所有者、授权服务器、客户端、资源服务器.协议的抽象流程为资源所有者通过授权服务器授权给客户端访问令牌，客户端使用该访问令牌能够访问资源所有者存放在资源服务器上的受保护资源.

在OAuth2.1协议中，根据不同的授权场景，分为2种不同的授权模式：客户端凭证模式和授权码模式.

客户端凭证模式适用于受保护资源本身属于客户端，该模式中不涉及资源所有者，客户端使用客户端id和客户端凭证获取访问令牌.在企业内部场景下，客户端与资源所有者不属于1个实体，因此客户端凭证模式不适用于本文研究场景.

授权码模式广泛应用于Web应用程序等需要资源所有者参与的授权场景中，与本文的研究场景一致，因此本文使用的是该模式.其基本流程为客户端首先向授权服务器请求1个授权码，并使用授权码获取访问令牌，以避免访问令牌泄露.但在协议具体实施过程中，攻击者可以通过授权码拦截攻击，对该模式成功实施攻击.授权码拦截攻击指的是攻击者通过监听或其他手段伪装成1个合法客户端，以截获授权码，并通过该授权码以及客户端凭证伪装成合法客户端与授权服务器进行通信，获取到访问令牌，从而访问资源服务器中的资源.

为了防御上述攻击，在OAuth2.1协议中，授权码模式基于交换码证明密钥(proof key for code exchange, PKCE)[6]设计.

如图1所示，客户端请求授权时，PKCE随机创建1个code_verifier，该code_verifier经过t_m加密变换后生成t_m(code_verifier).客户端请求授权码时，将t_m(code_verifier)和t_m发送到授权服务器；请求访问令牌时，将code_verifier发送到授权服务器，授权服务器使用t_m计算出t_m′(code_verifier)，与之前收到的t_m(code_verifier)进行比较，以确保客户端在本次授权过程中未被仿冒.授权码模式中加入PKCE后，攻击者即使拦截到授权码，也无法获得code_verifier，从而无法仿冒成客户端获取到访问令牌，因此PKCE能够有效防御授权码拦截攻击，提升OAuth协议安全性.

图1 基于PKCE的OAuth授权码模式时序图

2 统一认证授权框架设计

2.1 需求与可行性分析

设计统一认证授权系统有3个方面至关重要，分别为认证、授权和安全性.认证和授权是系统的基本功能，安全性是对正确认证和授权的保证.首先，在用户登录系统或需要访问系统内其他应用，以及应用挂载到核心应用时，需要对用户或应用进行认证；在认证后，需要通过授权将正确的权限授予用户或应用，使其只能访问权限范围内的资源.同时，系统需要保证正确的认证用户或应用身份，不能将某类系统用户或应用身份错误认证成系统的其他用户或应用，更不能将系统外的攻击者错误认证为系统的用户或应用；认证后，系统需要保证为用户或应用授予正确的权限，不会将权限错分、漏分、多分，尤其要保证权限没有遭到滥用、没有被攻击者恶意获取.

本文对近年在统一认证授权系统开发中所用的相关技术进行了归纳，详细情况如表1所示.

由表1可知，所有认证方案都实现了单点登录；大部分授权方案使用了OAuth2.0协议；安全性方面使用了密码学算法和访问控制模型；此外，使用了不同的技术对于信息交换效率[7]、认证授权效率[8]、读取速度[9]等问题进行了改善.

表1 统一认证授权系统开发技术表

基于以上分析，虽然不同的系统在开发中用到的具体实现技术有所不同，但是从框架角度上来看具有一致性.因此，针对企业内部的用户、应用和资源，设计一个统一认证授权框架，使开发人员能够基于该框架，快速构建适用于不同企业需求的统一认证授权系统是可行的.

2.2 整体框架设计

统一认证授权框架基于用户界面层、服务层和数据层3层架构构建，包含5个模块，分别为用户界面模块、服务模块、数据模块、基于角色的访问控制模型(role-based access control, RBAC)的权限管理模块和安全风险检测模块.具体设计方案如图2所示.

图2 基于OAuth2.1的统一认证授权框架

1) 用户界面模块向用户展示系统界面，负责与服务模块的认证服务器进行交互，协同服务模块完成对用户和应用的认证和授权.基于用户界面模块，认证和授权后的用户可以访问系统权限范围内的各种应用，实现用户对系统的友好访问.

2) 服务模块是本框架中的核心部分，负责框架中认证和授权业务逻辑的实现.服务模块为用户界面模块提供认证服务、授权服务和安全管理服务，同时基于数据模块提供的用户、应用和授权信息等数据信息，实现用户和应用的认证和授权.

3) 数据模块存储了用户和应用的信息、权限管理过程中的权限信息、授权过程中的授权信息等数据信息，为服务模块提供数据支撑.

4) 基于RBAC的权限管理模块对用户和应用的相关权限进行管理，包括权限设置、权限分发等.模块基于RBAC模型设计，使系统不仅能够正确授权，而且保证了正确授权是易于实施的.权限管理模块与安全风险检测模块结合，在使用RBAC模型设计静态访问策略的基础上，实现基于安全风险检测的动态权限管理，保证授权的正确性.

5) 安全风险检测模块是对系统运行过程中可能存在的安全风险进行检测.该模块基于日志数据，对用户和应用的正常访问行为进行刻画，并在此基础上建立安全风险检测模型，对用户和应用的安全风险进行检测，同时为实现动态权限管理提供基础，保证系统整体的安全性.

本框架设计不仅实现了认证和授权功能，同时兼顾了安全性.框架使用单点登录提升用户的体验度，并在3层架构的基础上，增加了权限管理模块和安全风险检测模块，提升了系统整体的安全性.本文后续对框架中核心的认证服务、基于PKCE的OAuth2.1授权服务以及安全性3个部分进行了详细的阐述.

2.3 认证服务

认证服务为授权服务提供了用户和应用身份鉴别功能.该服务实现了对用户和应用的认证、用户的单点登录.认证服务具体流程如图3所示：

图3 认证服务流程

认证服务分为用户认证和应用认证.用户认证时，需要先进行安全风险检测.当不存在安全风险时，用户可以选择使用用户名/密码认证或一次性验证码认证进行认证；如果存在安全风险，则需要将安全告警通知用户和管理员，同时使用用户名/密码认证和一次性验证码认证的多因子认证.应用认证与用户认证流程大体一致.当应用不存在安全风险时，使用客户端id和客户端凭证进行应用认证；如果应用存在安全风险，将安全告警通知管理员，并暂停该应用的认证服务，等待管理员后续操作.

用户的单点登录实现流程为挂载在系统内部的应用在认证身份后，向统一认证授权系统请求用户登录，如果用户未登录则返回登录页面；如果用户已经登录，则生成访问令牌返回给应用，应用使用访问令牌访问到用户信息，同时用户免登录访问到应用.

2.4 基于PKCE的OAuth2.1授权服务

授权服务是在用户或应用认证成功后，对用户或应用拥有的权限进行授予，使之能够访问权限范围内的资源.对于用户而言，用户在授权后能够通过使用访问令牌访问其权限内的所有应用；对于应用而言，应用在用户授权后能够通过使用访问令牌使用用户资源.

授权服务基于PKCE的OAuth2.1授权码模式设计，其工作时序如图4所示.

图4 基于PKCE的OAuth2.1授权码模式时序图

授权码在前端传送，访问令牌存储在后端，同时所有与授权服务器通信的过程也在后端完成，前后端分离的模式能够避免访问令牌的泄露.基于PKCE的OAuth2.1授权码模式开发不仅方便开发人员快速开发授权功能，同时也保证了授权服务较高的安全性.

2.5 安全性设计

系统安全性是正确认证、授权的保障.安全性设计包括整体系统安全性、授权服务安全性以及用户和应用数据安全性3个方面.

2.5.1 整体系统安全性

整体系统的安全性建立在安全风险检测模块之上.安全风险检测模块基于日志数据，对用户和应用的正常行为进行刻画，在此基础上，分别对用户和应用建立安全风险检测模型，并使用所建立的模型对用户和应用在系统运行过程中可能存在的安全风险进行检测，安全风险检测模块流程如图5所示.

图5 安全风险检测模块流程图

基于系统日志的安全风险检测模块，能够在安全风险出现时，及时发现并采取相关措施，提升了系统整体的安全性，该模块主要包括2个部分：建立检测模型和安全风险检测.

1) 建立安全风险检测模型.对系统中的日志数据进行收集和分析，对用户行为和应用行为进行研究，在此基础上，建立用户安全检测模型和应用安全风险检测模型.

2) 安全风险检测.在建立安全风险检测模型的基础上，对用户和应用在系统运行中的安全风险进行检测.用户出现安全风险时，根据安全风险的危险程度通过权限管理模块对用户权限进行限制或拒绝，同时使用多因子认证重新对用户认证，将日志数据、告警信息发送到安全管理服务，并使用邮件或短信方式通知用户和管理员；应用出现安全风险时，通过权限管理模块停止该权限，并将日志数据和告警信息发送至安全管理服务，由管理员进行处理.

2.5.2 授权服务安全性

授权服务中除了需要保证OAuth2.1协议过程的安全性外，还需要考虑如何能够正确、安全地将权限授予用户或应用.框架基于企业内部的应用场景，在该场景下权限管理方面存在以下问题：1)系统中的应用较多，且随着企业发展，应用会不断增加；2)用户多，人员变动较频繁，人员会阶段性地使用某些应用，具有较大的变动性；3)认证授权系统中存储了用户和应用的敏感信息，安全性要求高.

针对以上问题，框架使用了RBAC模型(基于角色的访问控制模型).但是其权限是静态设置的，无法在发现安全风险时及时对访问策略进行修改.因此框架在基于RBAC模型的基础上，结合安全风险检测模型对权限管理模块进行设计.具体流程如图6所示.

图6 权限管理流程图

1) 基于RBAC模型的静态访问控制.该模块基于不同场景下的安全需求分析，将安全需求细化，抽象出角色集，并规定角色和权限之间的对应关系，设计出相应的权限集，构建完整的RBAC模型.

2) 基于安全风险检测模块的动态访问控制.在基于RBAC模型得到静态权限集后，结合安全风险检测模块，一旦用户或应用存在安全风险，就及时地对用户或应用的静态权限集进行操作(如降低用户访问权限、禁止用户访问权限、停止应用接入权限等).

权限管理模块结合了RBAC模型和安全风险检测模块，能够在出现异常时，及时阻断安全风险，提高了权限管理的灵活性和安全性.

2.5.3 用户和应用数据安全性

安全管理模块用户对系统中用户和应用数据的安全进行保障.该模块分为2个部分：用户和应用数据管理以及安全风险检测告警管理.

1) 用户和应用数据管理：管理员可以对用户和应用数据进行查找、添加、删除、修改，同时也可以对用户和应用的权限进行管理.

2) 安全风险检测告警管理：安全风险检测模块检测到用户行为存在安全风险时，会将相关数据(日志和风险告警)保存并反馈给管理员；当应用行为存在安全风险时，会停止应用的接入，同时将相关信息反馈到管理员，由管理员进行操作(重新恢复应用接入权限等).

3 安全性分析

统一认证授权系统作为企业系统的主入口，安全性十分重要.在对系统设计和运行过程中可能出现的相关攻击进行研究的基础上，本文提出了该框架的解决思路，详细内容如表2所示：

该框架从认证和授权2个角度，对攻击者可能使用的攻击手段进行了分析和归纳.在实际运用过程中，攻击者可能会将各种攻击手段进行组合，对系统进行攻击.因此，防御措施既要相互独立，又能相互融合，以实现全方位的防御.在企业内部设计统一认证授权系统时，企业开发人员应遵循以上建议，将各个防御措施进行综合设计，以便提升系统的安全性，保证系统运行安全.

4 结束语

本文在OAuth2.1协议的PKCE授权码模式基础上，设计了一个适用于企业内部的统一认证授权框架.该框架为用户单点登录、应用认证、OAuth2.1授权、用户和应用数据管理、权限管理以及安全风险检测等问题提供了解决方案.通过可行性和安全性分析表明，该框架在实现正确认证、授权功能的基础上，能够很好地保证认证和授权过程的安全性.对开发人员能够在企业内部快速地建立一个统一、有效、安全的认证授权系统具有广泛的借鉴意义.