oauth2在分布式微服务架构下基于角色的权限设计(RBAC)

在前两节的基础上，对权限控制作进一步的分析与设计。

RBAC(Role-Base Access Control，基于角色的访问控制)

本篇内容基于个人理解，不当之处，欢迎批评指正。

前两篇内容：

• 【图文详解】搭建 Spring Authorization Server + Resource + Client 完整Demo
• 【oauth2 客户端模式】Spring Authorization Server + Resource + Client 资源服务间的相互访问

• 用户经过认证/授权后，进入客户端（认证中心给客户端发放令牌），客户端携带令牌访问对应的资源。
• 客户端是用户和资源之外的第三方，要想访问资源必须得到用户的允许。
• 用户拥有资源，通过客户端去访问，把访问权限赋于给了客户端。

• SCOPE：范围；指用户授权客户端可以访问的范围。客户端只能在这个范围内去访问。是针对客户端来说的。
• ROLE：角色；是用户的身份。是针对用户来说的。
• AUTH：权限；是角色所拥有的。角色与权限是多对多的关系；一个角色可以有多个权限，一个权限也可以同时被多个角色所拥有。权限也可以直接针对于用户，如果用户不指定角色，可以直接把权限赋于用户。

从图中可以看出，在每个里面的访问主体及权限是不同的（这里的权限是统称，包括SCOPE、ROLE、AUTH，不仅仅指AUTH）

• 当用户登录后，在认证中心内，访问主体就是用户，它的权限就是 ROLE（AUTH）
• 在客户端中，访问主体还是用户，但是权限发生了变化，增加了用户所授于客户端的SCOPE；共包含：ROLE（AUTH）和 SCOPE
• 客户端携带令牌访问资源，在资源服务器中访问主体就是客户端，权限只有：SCOPE；因为客户端是在用户授权下去访问的，所以在认证中心生成令牌时，只包括了用户授于的SCOPE，不可能把用户的身份ROLE也赋于客户端。

通过上面的分析可以发现，资源端只有 SCOPE，不可能用 ROLE 或 AUTH 去控制用户的访问。认证中心不负责访问资源，要想通过 ROLE 或 AUTH 去控制用户访问资源，只能在 客户端 去操作。资源API在客户端有对应的接口，要想控制资源API，就控制客户端的对应接口就可以了。只要用户能访问客户端的某个API接口，它就能访问与之对应的资源API。

• 资源API 面向 SCOPE 开放；

• 客户端API 面向 ROLE 或 AUTH 开放；

• 客户端

• 资源端

• 用户与角色

• 角色与权限

ROLE_1：包含 AUTH_1、AUTH_3

ROLE_2：包含 AUTH_2、AUTH_3、AUTH_4

• 客户端与资源的访问绑定关系是一一对应的，应该相应稳定。客户端能访问某个资源就提供一个接口。不能随时修改。

• 用户通过角色访问客户端，这个关系比较灵活， 相对松散。客户端中只需指定某个接口可以被哪些AUTH访问即可。

• 角色ROLE与权限AUTH的关系相对稳定，但可以比客户端和资源的关系灵活，可以修改编辑。

• 在项目设计阶段，应该首先确定客户端的种类，再基本确认项目中所涉及的角色。根据资源API功能，决定可以在哪些客户端中访问，需要哪些权限，应该把权限赋于哪种角色。