00-1010在一般领域，赋权是领导者通过为员工和下属提供更多自主权来实现组织目标的过程。
在计算机领域，授权是由信息系统指定的批准机构授予一个实体处理、存储或传输信息的权力。
在身份认证领域，授权是指在身份认证后，客户端可以有限地访问服务器资源的机制。
授权的含义
在已建立的用户系统中，当刷新面包的API需要判断当前访问用户是否可以访问当前资源时，需要构建自己的权限体系。授权是权限系统中非常重要的概念，是指判断用户拥有哪些权限的过程，与认证完全不同。
对于企业来说，授权可以明确组织成员之间的关系，使职责和边界更加清晰，便于公司管理；同时授权可以保证数据安全，防控风险，不同的权限允许不同的操作，可以防止用户恶意破坏、数据泄露、误操作等事故的发生。授权可以提高决策的效率。优秀的授权和权限管理可以使系统更容易操作，提高员工的工作效率。
从产品角度来看，授权可以保证产品系统的使用安全和数据安全，防止非法操作和数据泄露。授权还可以提高系统的可操作性和用户体验；此外，良好的授权功能将提升产品价值，使其在市场上更具竞争力。
为什么要进行「授权」？
授权模式主要包括基于OAuth 2.0流程的授权码模式和通过API接口到授权中心的用户授权集中验证。
授权模式
OAuth2框架是一个安全、轻量、标准的授权系统，用于帮助资源所有者、调用者和资源所有者完成授权过程。如果资源所有者不参与授权过程，可以使用client_credentials模式。该模式通常用于后端服务器的M2M模式。您可以在应用程序详细信息页面上获取应用程序的ID和密钥，并且您需要将它安全地存储在您的服务器中。
您可以使用OAuth2.0的client_credentials来模拟使用特定范围权限发布access_token:
卷曲请求开机自检
-URL https://$ { YOUR _ AUTHING _ DOMAIN }/oidc/token \
-标头“accept:应用程序/JSON ”\
-标头“缓存控制：无缓存”
-header ‘ content-type : application/x-www-form-URL encoded ‘ \
-data ‘ grant _ type=client _ credentials scope=customscopeclient _ id=client _ id client _ secret=client _ secret ‘身份验证将根据调用方请求的资源和上下文动态决定它拥有哪个AccessToken。并返回被拒绝的范围：
{
access_token’: ‘ .
token_type’: ‘承载者’，
: 3599年到期，
作用域’ : ‘用户’，
scope_rejected’: ‘xxx yyy ‘
}此access_token的权限列表在哪个范围内，用空格分隔。您可以通过后端的范围判断用户拥有什么权限。
当授权过程涉及到需要资源所有者参与授权时，可以使用OAuth2.0框架中的授权码模式。您需要将权限项放在启动授权的链接的范围参数中，例如：
https://$ { YOUR _ AUTHING _ DOMAIN }/oidc/AUTH？Client_id={您的应用程序id } scope=open idbook : readbook : delete redirect _ uri={您的业务回调地址} state={ random string } response _ type=code资源所有者需要点击链接，然后转到登录页面，在该页面中，资源所有者对自己进行身份验证，并将资源授权给调用方。
认证授权完成后，浏览器会跳转到业务回调地址，通过URL传递代码授权码。调用者可以使用这个代码授权代码来验证，以换取一个带有权限的访问令牌，用于获取资源端的资源。
令牌的代码如下：
卷曲请求开机自检
-URL https://$ { YOUR _ AUTHING _ DOMAIN }/oidc/token \
-标题“内容类型：应用程序/x-www-form-urlencoded”
-data client _ ID={应用程序ID} \
-数据客户端_ secret={应用程序密钥} \
-数据授权类型=授权代码\
–
data redirect_uri={回调地址} \
–data code={授权码}
同样，Authing 会根据调用方请求的资源和上下文环境，动态的决定颁发具备哪些权限的 AccessToken。并返回被拒绝的 scope：
{
“access_token”: “…”,
“token_type”: “Bearer”,
“expires_in”: 3599,
“scope”: “openid book:read”,
“scope_rejected”: “book:delete”
}
当然，资源方必须在返回资源前，验证调用者是否携带了具备权限的 AccessToken，当一切检验通过，就可以安全地返回资源。
使用权限 API
除了使用 OAuth2.0 的 client_credentials 模式，还可以使用通用的权限 API，通过权限 API 创建角色、给角色授权角色、判断用户是否具备某个权限等。我们支持 Node.js、Python、Java、PHP、C# 等语言的 SDK，详情请见文档。
权限模型
目前，基于角色的访问控制（RBAC）和基于属性的访问控制（ABAC）是被大家广泛采用的两种权限模型，二者各有优劣。
RBAC 模型构建起来更加简单，缺点在于无法做到对资源细粒度地授权（都是授权某一类资源而不是授权某一个具体的资源）；ABAC 模型构建相对比较复杂，学习成本比较高，优点在于细粒度和根据上下文动态执行。
基于角色的访问控制（RBAC）
什么是 RBAC？
基于角色的访问控制（Role-based access control，简称 RBAC），指的是通过用户的角色（Role）赋予其相关权限，这实现了细粒度的访问控制，并提供了一个相比直接授予单个用户权限，更简单、可控的管理方式。
当使用 RBAC 时，通过分析系统用户的实际情况，基于共同的职责和需求，将他们分配给不同的角色。然后可以授予每个用户一个或多个角色，每个角色具有一个或多个权限，这种 用户-角色、角色-权限 间的关系，让我们可以不用再单独管理单个用户，用户从具备的角色里面继承所需的权限，从而使得用户赋权这件事变得更加简单。
RBAC 的使用场景
以一个简单的场景为例（Gitlab 的权限系统），用户系统中有 Admin、Maintainer、Operator 三种角色，这三种角色分别具备不同的权限，比如只有 Admin 具备创建代码仓库、删除代码仓库的权限，其他的角色都不具备。
我们授予某个用户「Admin」这个角色，他就具备了「创建代码仓库」和「删除代码仓库」这两个权限。
不直接给用户授权策略，是为了之后的扩展性考虑。比如存在多个用户拥有相同的权限，在分配的时候就要分别为这几个用户指定相同的权限，修改时也要为这几个用户的权限进行一一修改。有了角色后，我们只需要为该角色制定好权限后，将相同权限的用户都指定为同一个角色即可，便于权限管理。
基于属性的访问控制（ABAC）
什么是 ABAC？
基于属性的访问控制（Attribute-Based Access Control，简称 ABAC）是一种灵活的授权模型，通过一个或一组属性来控制是否有对操作对象的权限。
其中，ABAC 中的 A，也就是属性（Attribute），用于表示 subject、object 或者环境特征的特点，属性使用 key-value 的形式来存储这些信息，比如我在公司的 role 是 developer，role 是 key，developer 是 value。
ABAC 属性通常来说分为四类：用户属性（如用户年龄），环境属性（如当前时间），操作属性（如读取）和对象属性（如一篇文章，又称资源属性），所以理论上能够实现非常灵活的权限控制。
ABAC 的使用场景
比如，在北京的公司员工明天将用公司内网参加会议培训。其中，「北京」、「公司内网」是环境属性，「参加会议培训」是操作属性。在需要根据这些属性来动态计算权限的时候，RBAC 授权模型将无法满足需求。这个时候就需要使用 ABAC 授权模型。
在 ABAC 权限模型下，你可以轻松地实现以下权限控制逻辑：
授权某编辑具体某本书的编辑权限；当一个文档的所属部门跟用户的部门相同时，用户可以访问这个文档；当用户是一个文档的拥有者并且文档的状态是草稿，用户可以编辑这个文档；早上九点前禁止 A 部门的人访问 B 系统；在除了上海以外的地方禁止以管理员身份访问 A 系统；
上述的逻辑中有几个共同点：
具体到某一个而不是某一类资源；具体到某一个操作；能通过请求的上下文（如时间、地理位置、资源 Tag）动态执行策略；
如果浓缩到一句话，你可以细粒度地授权在何种情况下对某个资源具备某个特定的权限。
RBAC 授权模型是基于角色的访问控制，当面对大型企业与组织时，RBAC 授权模型需要维护大量的角色和授权关系，ABAC 授权模型则会更加灵活。此外，当资源不断增多时，RBAC 授权模型需要维护所有的相关角色，而 ABAC 授权模型只需根据相关属性进行维护，有更强的拓展性。
借助 Authing 实现权限模型
在 Authing 的权限系统中，我们同时支持 RBAC 和 ABAC 的权限模型，即兼顾了管理的效率和授权的粒度。在 Authing 控制台的权限管理模块中可以对资源和角色进行统一管理，并可以采用个性化的授权规则将资源的操作权限授权给角色或者某个用户。
在进行授权的时候首先选择授权用户的主体，除了可以对用户和角色进行授权，还可以对分组和某个组织节点进行授权，这种不同维度的授权模型可以给授权管理带来极大的便利。
我们可以给每一个授权定义授权规则——允许或拒绝某个资源在某些条件下访问。
在控制台定义好授权资源之后，你可以将 Authing 中定义的权限模型通过 API 的形式集成在自己的项目之中，实现对资源权限的控制。
首先初始化 Management SDK：
这里以 Node SDK 为例，我们同时还支持 Python、Java、C#、PHP 等语言的 SDK，详情请见 https://docs.authing.cn/
import { ManagementClient } from ‘authing-js-sdk’;
const managementClient = new ManagementClient({
userPoolId: “YOUR_USERPOOL_ID”,
secret: “YOUR_USERPOOL_SECRET”
});
调用 managementClient.acl.isAllowed 方法，三个参数分别为：
userId: 用户 ID，用户可以被直接授权特定资源的操作，也可以继承角色被授权的权限。resource: 资源标志符，如 repository:123 表示 ID 为 123 的代码仓库，repository:* 表示代码仓库这一类资源。action: 特定操作，如repository:Delete表示删除代码仓库这个操作。
const { totalCount, list } = await managementClient.acl.isAllowed(“USER_ID”, “repository:123”, “repository:Delete”);
Authing 策略引擎会根据你配置的权限策略，动态执行策略，最后返回 true 或者 false，你只需要根据返回值就能判断用户是否具备操作权限。
总结
Authing 不仅通过用户、角色这两种对象实现了 RBAC 模型的角色权限继承，还在此之上实现了如何进行更细粒度、动态的 ABAC 权限模型。这是一个渐进的过程，随着业务的复杂性不断变大，你可以基于 Authing 强大而又灵活的权限系统，快速构建出适合你业务场景的权限模型。
如果你喜欢我们的内容，欢迎关注公众号「Authing 身份云」和访问我们的官网，更多有趣的内容等你来看～