CN117118751B - 基于OAuth2的访问控制模型的拓展方法及其应用 - Google Patents

Abstract

本申请提出了基于OAuth2的访问控制模型的拓展方法及其应用，包括以下步骤：通过认证中心对用户颁发访问令牌，作为授权操作，该访问令牌绑定用户的角色和权限信息；通过子系统响应于用户访问请求，验证用户的访问令牌并从认证中心获取该访问令牌绑定的用户的角色和权限信息，按照子系统自身业务返回给用户资源，作为鉴权操作；在用户发生变更时，通过认证中心将变更信息通知给各子系统，各子系统依据自身业务授权策略消费该变更信息；通过认证中心提供授权规则的配置以及对应的操作界面，以使得各子系统能够根据自身业务需求预设授权策略。

Description

基于OAuth2的访问控制模型的拓展方法及其应用

技术领域

本申请涉及计算机网络安全技术领域，特别是涉及基于OAuth2的访问控制模型的拓展方法及其应用。

背景技术

OAuth2协议被广泛应用于用户认证和授权。然而现有的OAuth2协议在处理各个子系统之间的角色授权时存在一些限制。例如，对于不同的子系统，可能需要不同的角色授权策略，比如区分租户、动态角色授权或者是层次化的权限授权控制。目前，在OAuth2协议中并没有对这些业务需求给出相应的拓展方法。

在OAuth2协议中并未对资源服务器（以下简称子系统）的角色做出定义以及制定相应的规则和流程，而传统的基于OAuth2搭建的中心化认证授权系统中，采用的是角色（Role）和作用域（Scope）一起组合而成的一种带作用域的基于角色的访问控制模型（Role-Based Access Control with Scope，RBAC with Scope），以满足授权服务器（以下简称认证中心）的角色管理和访问控制的需求。

然而，由于不同的子系统对角色管理和权限控制有着各自不同的业务需求，因此这种单一的访问控制模型并不能很好地满足子系统的多样化的业务需求。例如，在面对动态角色授权、层次化的权限授权等需求时，认证中心就无法提供支持，需要各个子系统独立管理权限和鉴权。而这种子系统独立管理和鉴权的方式又违背了中心化系统的核心设计原则，继而引发子系统之间不得不进行权限信息的交互、带来复杂的处理逻辑；认证中心也无法管理子系统的权限、存在安全隐患等问题。

因此，亟待一种基于OAuth2的访问控制模型的拓展方法及其应用，以解决现有技术存在的问题。

发明内容

本申请实施例提供了基于OAuth2的访问控制模型的拓展方法及其应用，针对目前技术无法满足业务拓展需求的问题。

本申请核心技术主要是在OAuth2协议的基础上，拓展出一个具备权限管理、授权等功能的功能模块：它包含触发器，消息队列，自动授权模块，授权规则配置模块以及一套用于和子系统进行权限信息交换的API。

第一方面，本申请提供了基于OAuth2的访问控制模型的拓展方法，所述方法包括以下步骤：

通过认证中心对用户颁发访问令牌，作为授权操作，该访问令牌绑定用户的角色和权限信息；

通过子系统响应于用户访问请求，验证用户的访问令牌并从认证中心获取该访问令牌绑定的用户的角色和权限信息，按照子系统自身业务返回给用户资源，作为鉴权操作；

在用户发生变更时，通过认证中心将变更信息通知给各子系统，各子系统依据自身业务授权策略消费该变更信息；

通过认证中心提供授权规则的配置以及对应的操作界面，以使得各子系统能够根据自身业务需求预设授权策略；

其中，授权操作与鉴权操作为异步处理且无耦合关系。

进一步地，用户的角色和权限信息来源于自动授权装置，该自动授权装置安装于认证中心，通过认证中心进行权限的管理和授权，且自动授权装置包括用于和子系统进行权限信息交换的API。API 是应用程序编程接口（Application Programming Interface）的缩写，是一组规则和协议，允许不同软件应用程序之间相互通信和互操作。API 定义了应用程序如何与其他软件组件（通常是库、框架、操作系统或外部服务）进行交互，以实现特定功能或访问特定资源。API 充当了不同软件组件之间的中介，使它们可以协同工作，而不必了解彼此的内部工作细节。

进一步地，自动授权装置包括触发器，通过该触发器在用户发生变更时发生动作，以使得认证中心将变更信息通知给各子系统。

进一步地，自动授权装置还包括消息队列，以使得认证中心能够通过该消息队列将变更信息通知给各子系统。消息队列是一种在分布式应用程序中用于异步通信的技术，它允许不同组件或系统之间通过发送和接收消息来进行通信。消息队列系统通常用于解耦应用程序的不同部分，以便它们可以独立运行和扩展，同时保持通信的可靠性和可伸缩性。

进一步地，自动授权装置包括授权规则配置模块，通过该授权规则配置模块提供授权规则的配置功能。

进一步地，每个子系统能够创建角色并记录该角色的Client ID属性和Scope属性，且子系统能够编辑和授权拥有相同Client ID的角色。

进一步地，当用户从认证中心跳转至子系统时，认证中心根据子系统提供的Client ID属性和Scope属性生成相应的访问令牌。

第二方面，本申请提供了一种基于OAuth2的访问控制模型的拓展装置，包括：

自动授权装置，安装于认证中心，包括触发器、消息队列、授权规则配置模块、自动授权模块以及用于和子系统进行权限信息交换的API；

认证中心，对用户颁发访问令牌，作为授权操作，该访问令牌绑定用户的角色和权限信息；在用户发生变更时，触发器动作，通过消息队列将变更信息通知给各子系统，各子系统依据自身业务授权策略调取自动授权模块消费该变更信息；通过授权规则配置模块提供授权规则的配置以及对应的操作界面，以使得各子系统能够根据自身业务需求预设授权策略；

子系统，能够创建角色并记录该角色的Client ID属性和Scope属性，且能够编辑和授权拥有相同Client ID的角色；响应于用户访问请求，验证用户的访问令牌并从自动授权装置获取该访问令牌绑定的用户的角色和权限信息，按照子系统自身业务返回给用户资源，作为鉴权操作；

其中，授权操作与鉴权操作为异步处理且无耦合关系。

第三方面，本申请提供了一种电子装置，包括存储器和处理器，存储器中存储有计算机程序，处理器被设置为运行计算机程序以执行上述的基于OAuth2的访问控制模型的拓展方法。

第四方面，本申请提供了一种可读存储介质，可读存储介质中存储有计算机程序，计算机程序包括用于控制过程以执行过程的程序代码，过程包括根据上述的基于OAuth2的访问控制模型的拓展方法。

本申请的主要贡献和创新点如下：1、与现有技术相比，本申请将授权和鉴权动作设计为异步处理，彼此之间也没有耦合关系。使得本申请拥有极高的稳定性、灵活性和拓展能力。并且子系统在鉴权过程中只需判断令牌中是否有角色和权限，而不用再计算角色和角色之间的关联关系、不用再实现将角色授权给用户的功能。这极大地简化子系统接入认证系统的步骤。

2、与现有技术相比，本申请能避免子系统和子系统之间权限信息的交互，这种解耦的设计能极大降低系统复杂度，同时也符合中心化系统的设计原则。

3、与现有技术相比，遵循设计模式的开闭原则，不对Oauth2协议框架做修改，而是通过拓展方式，将各种类型的访问控制模型封装起来，通过配置的方式适配到各个子系统。因此本申请有很高的可拓展性、可复用性和可维护性。

本申请的一个或多个实施例的细节在以下附图和描述中提出，以使本申请的其他特征、目的和优点更加简明易懂。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的基于OAuth2的访问控制模型的拓展方法的系统架构图；

图2是本申请触发器和自动授权模块工作流程图；

图3是授权规则配置的操作页面的原型图；

图4是根据本申请实施例的电子装置的硬件结构示意图。

具体实施方式

这里将详细的对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。

需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。

实施例一

本申请旨在提出一种基于OAuth2的访问控制模型的拓展方法，具体地，参考图1，所述方法包括以下步骤：

通过认证中心对用户颁发访问令牌，作为授权操作，该访问令牌绑定用户的角色和权限信息；

在本实施例中，当用户发起请求想要访问子系统时，需带上访问令牌（AccessToken），该令牌由认证中心颁发，并且认证中心在颁发访问令牌的过程中会从自动授权装置处获取用户的角色和权限信息，并绑定到令牌上，此过程为认证中心的授权。

通过子系统响应于用户访问请求，验证用户的访问令牌并从认证中心获取该访问令牌绑定的用户的角色和权限信息，按照子系统自身业务返回给用户资源，作为鉴权操作；

在本实施例中，子系统在校验用户请求时会从认证中心处获取令牌绑定的角色和权限信息，并按照自身业务决定给用户返回什么资源，此过程为子系统的鉴权。

作为自动授权装置的第一种使用方式：在用户发生变更时，通过认证中心将变更信息通知给各子系统，各子系统依据自身业务授权策略消费该变更信息；

在本实施例中，如图2所示，由子系统通过API操作自动授权装置，主动对用户的角色和权限进行管理：认证中心在用户发生变更时（触发器动作），会通过消息队列将此信息通知到子系统，各个子系统可以根据自身系统的业务需求（授权策略）来消费该消息，并可以通过API操作自动授权装置对用户的角色和权限进行管理。

作为自动授权装置的第二种使用方式：通过认证中心提供授权规则的配置以及对应的操作界面，以使得各子系统能够根据自身业务需求预设授权策略；

在本实施例中，如图3所示，认证中心提供授权规则配置模块以及相应的操作界面，各子系统管理员可以根据自身系统的业务需求预先配置好授权策略，这样认证中心就可以在用户发生变更时依据配置进行自动授权。

其中，授权操作与鉴权操作为异步处理且无耦合关系。

在本实施例中，在OAuth2协议的基础上，拓展出一个具备权限管理、授权等功能的功能模块（即为自动授权装置）：它包含触发器、消息队列、自动授权模块、授权规则配置模块以及一套用于和子系统进行权限信息交换的API。通过将自动授权装置安装在认证中心，由认证中心来进行权限的管理和授权，这也是中心化系统的根本原则；如此，子系统只需实现鉴权，认证中心不限制子系统采用何种方式进行访问控制。

其中，“自动授权模块”是整个自动授权装置的一部分，它的输入有2个：一是子系统管理员输入的配置规则，二是触发器输入的用户状态、属性变更消息。它的输出是：用户和角色（权限）的关联关系，输出结果保存到数据库。

这样在认证中心查询用户角色（权限）时可以直接去数据库获取结果，不必再做计算。

优选地，子系统可以创建角色，创建的角色会记录下Client ID属性（Oauth2协议中定义的客户端ID）和Scope属性（OAuth2协议中的作用域）。还可以编辑和授权拥有相同Client ID的角色。而且当用户由认证中心转跳到子系统时，认证中心根据子系统的提供的Client ID 和Scope生成相应的访问令牌（Access Token），令牌中会额外携带相应的角色信息。以上规则旨在OAuth2协议的基础上，补充了对于子系统角色的定义。这样做使得子系统仍然能以接入传统的基于OAuth2搭建的中心化认证授权系统的接入方式接入认证中心，且获取访问令牌的方式、校验访问令牌的方式、管理访问令牌的方式均不需要做变更。

实施例二

基于相同的构思，如图1所示，本申请还提出了一种基于OAuth2的访问控制模型的拓展装置，包括：

自动授权装置，安装于认证中心，包括触发器、消息队列、授权规则配置模块、自动授权模块以及用于和子系统进行权限信息交换的API；

认证中心，对用户颁发访问令牌，作为授权操作，该访问令牌绑定用户的角色和权限信息；在用户发生变更时，触发器动作，通过消息队列将变更信息通知给各子系统，各子系统依据自身业务授权策略调取自动授权模块消费该变更信息；通过授权规则配置模块提供授权规则的配置以及对应的操作界面，以使得各子系统能够根据自身业务需求预设授权策略；

子系统，能够创建角色并记录该角色的Client ID属性和Scope属性，且能够编辑和授权拥有相同Client ID的角色；响应于用户访问请求，验证用户的访问令牌并从自动授权装置获取该访问令牌绑定的用户的角色和权限信息，按照子系统自身业务返回给用户资源，作为鉴权操作；

其中，授权操作与鉴权操作为异步处理且无耦合关系。

为了更好地解释本系统，本实施例设计了如下一个有层次化访问控制的场景示例：

有个子系统S中，D部门下的用户可以拥有权限（拥有R1这个角色）去查询人员薪资，并且这个权限可以往下继承，即D部门的子部门D’部门下的用户也应拥有R1角色。但当用户离开了D部门，应自动移除用户的R1角色；同理，当用户只是从D部门的一个子部门D’转派到另一个子部门D’’时，用户还是拥有查询人员薪资的权限（拥有R1角色不变）。

在该场景中，用户的角色随着用户所属部门的变化而变化，并且部门信息是一类有上下层次关系的数据。将部门信息作为授权依据是非常定制化的需求，且通用性不强。

此时，该子系统S的管理员在认证中心用户管理页面中，进行了将用户U从原先的D’部门转派到D’’ 部门的操作。

以下是自动授权装置中各个模块的定义和在该场景中的具体响应流程：

触发器：当用户的指定属性发生变化，触发器会被触发，获取变更数据并调用自动授权模块的对应方法进行处理。在本场景中，当子系统S的管理员完成了对用户U的更改部门操作后，触发起调用自动授权模块的方法，将“用户U离开了部门D’”、“用户U加入了部门D’’”这两条数据传入给自动授权模块。

自动授权模块：该模块是可拓展的，自动授权模块可以依据不同的场景，匹配到相应的实现代码，自动授权模块最终的输出必须是统一的：将用户和角色关联起来，并持久化到数据库。

在本申请的场景中，对应实现的代码的逻辑如下：

在被触发器调用方法后，从数据库中查询授权规则配置（授权规则配置来自图3，由子系统S的管理员预先配置）、部门上下级关系信息。自动授权模块能进行逻辑运算（图2），判断是否为U用户添加R1角色。并将结果保存入数据库。

授权规则配置模块：可以依据不同的场景设计多种规则配界面。

其中，规则配界面应如图3，具体如下：

1）指定一个部门，当用户加入/离开指定部门时将会授予/移除指定的角色操作；

2）是否激活该规则；

3）是否将该规则也生效于子部门。

用户的权限信息：数据结构符合RBAC模型，用户-权限/用户-角色，多对多关联。RBAC指的是角色基于访问控制（Role-Based Access Control）模型，它是一种用于管理和控制计算机系统和应用程序访问权限的安全模型。RBAC 的核心思想是将用户、资源和操作分为角色，然后通过定义哪些角色可以执行哪些操作来管理访问权限。

消息对象：用于承载用户和部门之间关联关系的对象，包含用户ID，部门ID，加入/离开的标识符。

子系统安全框架：各子系统各自的安全框架自主从认证中心获取用户的权限信息，从而进行访问控制。

因此，本系统的运行流程如下：

1）子系统S的管理员预先进行授权规则的配置，如图3所示：规则1对部门D生效，当用户加入部门D时，执行为该用户添加角色R1的操作。

2）在本申请提供的场景中，某用户U从部门D’转派到部门D’’的动作被触发器捕获，触发器响应，调用了2次自动授权模块的方法并传入参数，第一次为“用户U离开了部门D’”第二次为“用户U加入了部门D’’”。

3）见图2，自动授权模块在步骤1）中读取到了规则1，在第一次方法被调用时计算出不做任何处理的结果，在第二次方法被调用时将R1角色 授权给了用户U，并将这个结果保存到了数据库。

在未来用户U想要访问子系统S时，认证中心会从数据库中获取到用户U拥有R1角色的信息，并在颁发令牌的过程中，将该用户拥有角色R1的信息也写入令牌中，子系统S根据令牌中的角色信息，作出相应的安全控制。

值得一提的是，本申请只举例了用户离开或加入部门这一种场景的规则配置页面，而自动授权模块可以拓展出更多种类的规则配置页面和相应的实现代码。即可以拓展各种各样的访问控制模型。通过这样的方式拓展，就可以到达不对OAuth2协议框架做修改就能适配子系统多样化的业务需求的目的。

实施例三

本实施例还提供了一种电子装置，参考图4，包括存储器404和处理器402，该存储器404中存储有计算机程序，该处理器402被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

具体地，上述处理器402可以包括中央处理器（CPU），或者特定集成电路（ApplicationSpecificIntegratedCircuit，简称为ASIC），或者可以被配置成实施本申请实施例的一个或多个集成电路。

其中，存储器404可以包括用于数据或指令的大容量存储器404。举例来说而非限制，存储器404可包括硬盘驱动器（HardDiskDrive，简称为HDD）、软盘驱动器、固态驱动器（SolidStateDrive，简称为SSD）、闪存、光盘、磁光盘、磁带或通用串行总线（UniversalSerialBus，简称为USB）驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器404可包括可移除或不可移除（或固定）的介质。在合适的情况下，存储器404可在数据处理装置的内部或外部。在特定实施例中，存储器404是非易失性（Non-Volatile）存储器。在特定实施例中，存储器404包括只读存储器（Read-OnlyMemory，简称为ROM）和随机存取存储器（RandomAccessMemory，简称为RAM）。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM（ProgrammableRead-OnlyMemory，简称为PROM）、可擦除PROM（ErasableProgrammableRead-OnlyMemory，简称为EPROM）、电可擦除PROM（ElectricallyErasableProgrammableRead-OnlyMemory，简称为EEPROM）、电可改写ROM（ElectricallyAlterableRead-OnlyMemory，简称为EAROM）或闪存（FLASH）或者两个或更多个以上这些的组合。在合适的情况下，该RAM可以是静态随机存取存储器（StaticRandom-AccessMemory，简称为SRAM）或动态随机存取存储器（DynamicRandomAccessMemory，简称为DRAM），其中，DRAM可以是快速页模式动态随机存取存储器404（FastPageModeDynamicRandomAccessMemory，简称为FPMDRAM）、扩展数据输出动态随机存取存储器（ExtendedDateOutDynamicRandomAccessMemory，简称为EDODRAM）、同步动态随机存取内存（SynchronousDynamicRandom-AccessMemory，简称SDRAM）等。

存储器404可以用来存储或者缓存需要处理和/或通信使用的各种数据文件，以及处理器402所执行的可能的计算机程序指令。

处理器402通过读取并执行存储器404中存储的计算机程序指令，以实现上述实施例中的任意基于OAuth2的访问控制模型的拓展方法。

可选地，上述电子装置还可以包括传输设备406以及输入输出设备408，其中，该传输设备406和上述处理器402连接，该输入输出设备408和上述处理器402连接。

传输设备406可以用来经由一个网络接收或者发送数据。上述的网络具体实例可包括电子装置的通信供应商提供的有线或无线网络。在一个实例中，传输设备包括一个网络适配器（Network Interface Controller，简称为NIC），其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输设备406可以为射频（Radio Frequency，简称为RF）模块，其用于通过无线方式与互联网进行通讯。

输入输出设备408用于输入或输出信息。

实施例四

本实施例还提供了一种可读存储介质，可读存储介质中存储有计算机程序，计算机程序包括用于控制过程以执行过程的程序代码，过程包括根据实施例一的基于OAuth2的访问控制模型的拓展方法。

需要说明的是，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

通常，各种实施例可以以硬件或专用电路、软件、逻辑或其任何组合来实现。本申请的一些方面可以以硬件来实现，而其他方面可以由控制器、微处理器或其他计算设备执行的固件或软件来实现，但是本申请不限于此。尽管本申请的各个方面可以被示出和描述为框图、流程图或使用一些其他图形表示，但是应当理解，作为非限制性示例，本文中描述的这些框、装置、系统、技术或方法可以以硬件、软件、固件、专用电路或逻辑、通用硬件或控制器或其他计算设备或其某种组合来实现。

本申请的实施例可以由计算机软件来实现，该计算机软件由移动设备的数据处理器诸如在处理器实体中可执行，或者由硬件来实现，或者由软件和硬件的组合来实现。包括软件例程、小程序和/或宏的计算机软件或程序(也称为程序产品)可以存储在任何装置可读数据存储介质中，并且它们包括用于执行特定任务的程序指令。计算机程序产品可以包括当程序运行时被配置为执行实施例的一个或多个计算机可执行组件。一个或多个计算机可执行组件可以是至少一个软件代码或其一部分。另外，在这一点上，应当注意，如图中的逻辑流程的任何框可以表示程序步骤，或者互连的逻辑电路、框和功能，或者程序步骤和逻辑电路、框和功能的组合。软件可以存储在诸如存储器芯片或在处理器内实现的存储块等物理介质、诸如硬盘或软盘等磁性介质，以及诸如例如DVD及其数据变体、CD等光学介质上。物理介质是非瞬态介质。

本领域的技术人员应该明白，以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以作出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims (9)

1.基于OAuth2的访问控制模型的拓展方法，其特征在于，包括以下步骤：

通过认证中心对用户颁发访问令牌，作为授权操作，该访问令牌绑定用户的角色和权限信息；

通过子系统响应于用户访问请求，验证用户的访问令牌并从所述认证中心获取该访问令牌绑定的用户的角色和权限信息，按照子系统自身业务返回给用户资源，作为鉴权操作；

在用户发生变更时，通过所述认证中心将变更信息通知给各所述子系统，各所述子系统依据自身业务授权策略处理该变更信息；

通过所述认证中心提供授权规则的配置以及对应的操作界面，以使得各所述子系统能够根据自身业务需求预设授权策略；

其中，所述授权操作与所述鉴权操作为异步处理且无耦合关系；

其中，用户的角色和权限信息来源于自动授权装置，该自动授权装置安装于所述认证中心，通过所述认证中心进行权限的管理和授权，且所述自动授权装置包括用于和所述子系统进行权限信息交换的API。

2.如权利要求1所述的基于OAuth2的访问控制模型的拓展方法，其特征在于，所述自动授权装置包括触发器，通过该触发器在用户发生变更时发生动作，以使得所述认证中心将变更信息通知给各所述子系统。

3.如权利要求2所述的基于OAuth2的访问控制模型的拓展方法，其特征在于，所述自动授权装置还包括消息队列，以使得所述认证中心能够通过该消息队列将变更信息通知给各所述子系统。

4.如权利要求1所述的基于OAuth2的访问控制模型的拓展方法，其特征在于，所述自动授权装置包括授权规则配置模块，通过该授权规则配置模块提供授权规则的配置功能。

5.如权利要求1-4任意一项所述的基于OAuth2的访问控制模型的拓展方法，其特征在于，每个所述子系统能够创建角色并记录该角色的Client ID属性和Scope属性，且所述子系统能够编辑和授权拥有相同Client ID的角色。

6.如权利要求5所述的基于OAuth2的访问控制模型的拓展方法，其特征在于，当用户从所述认证中心跳转至所述子系统时，所述认证中心根据所述子系统提供的Client ID属性和Scope属性生成相应的访问令牌。

7.一种基于OAuth2的访问控制模型的拓展装置，其特征在于，包括：

自动授权装置，安装于认证中心，包括触发器、消息队列、授权规则配置模块、自动授权模块以及用于和子系统进行权限信息交换的API；

认证中心，对用户颁发访问令牌，作为授权操作，该访问令牌绑定用户的角色和权限信息；在用户发生变更时，触发器动作，通过消息队列将变更信息通知给各子系统，各子系统依据自身业务授权策略调取自动授权模块处理该变更信息；通过授权规则配置模块提供授权规则的配置以及对应的操作界面，以使得各子系统能够根据自身业务需求预设授权策略；

子系统，能够创建角色并记录该角色的Client ID属性和Scope属性，且能够编辑和授权拥有相同Client ID的角色；响应于用户访问请求，验证用户的访问令牌并从自动授权装置获取该访问令牌绑定的用户的角色和权限信息，按照子系统自身业务返回给用户资源，作为鉴权操作；

其中，授权操作与鉴权操作为异步处理且无耦合关系。

8.一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行权利要求1至6任一项所述的基于OAuth2的访问控制模型的拓展方法。

9.一种可读存储介质，其特征在于，所述可读存储介质中存储有计算机程序，所述计算机程序包括用于控制过程以执行过程的程序代码，所述过程包括根据权利要求1至6任一项所述的基于OAuth2的访问控制模型的拓展方法。