1. 认证授权概念

三个基本概念：

• 认证
• 会话
• 授权

1.1 认证

     用户认证就是判断一个用户的身份是否合法的过程,用户去访问系统资源时系统要求验证用户的身份信息,身份合法方可继续访问,不合法则拒绝访问。常见的用户身份认证方式有:用户名密码登录,二维码登录,手机短信登录,指纹认证等方式

认证的目的：保护系统的隐私数据与资源，用户的身份合法可访问该系统的资源

1.2 会话

    用户认证通过后，为了避免用户的每次操作都进行认证可将用户的信息保存在会话中。会话就是系统为了保持当前用户的登录状态所提供的机制，常见的有基于Session方式合Token方式等

① session方式

    交互流程：用户认证成功后，在服务端生成用户相关的数据保存在session(当前会话)中，发给客户端的session_id存放到cookie中，这样用户客户端请求时带上session_id就可以验证服务器端是否存在session数据，以此完成用户的合法性效验，当用户退出系统或session过期销毁时，客户端session_id也就无效

② token方式

    交互流程：用户认证成功后，服务端生成一个token发给客户端，客户端可以放到cookie或者localStorage、sessionStorage等存储中，每次请求时带上token，服务端接收到token通过验证后即可确认用户身份

基于session的认证方式由Servlet规范定制，服务端要存储session信息需要占用内存资源，客户端需要支持cookie; 基于token的方式则一般不需要服务端存储token，并且不限制客户端的存储方式；前后端分离的架构系统基于token保持会话更合适

1.3 授权

    认证是为了保证用户的合法性，授权则是为了更细粒度的对隐私数据进行划分，授权是在认证通过后控制不同用户能够访问不同的资源

授权的作用：授权是用户认证通过根据用户的权限来控制用户访问资源的过程，有资源的访问权限则正常访问，没有权限则拒绝访问

2. 授权的数据模型

授权即如何对用户访问资源进行控制，它的实现主要有三大部分：

1. 主体：主体一般指用户、也可以是程序等需要访问系统的资源
2. 资源：系统菜单、页面、按钮、代码方法、系统信息等，资源进一步区分又分为功能资源和数据资源
3. 权限/许可：规定了用户对资源的操作许可，权限离开资源是没有意义的，如用户查询权限、用户添加权限

资源分类：

• 功能资源：对应web系统每个功能资源通常对应一个URL，如电商系统的菜单、页面、按钮、代码方法都属于系统功能资源
• 数据资源：它通常对应着数据权限，如电商系统的商品信息、订单信息。数据资源由资源类型和资源实例组成

主体、资源、权限关系图如下：以电商系统的商品为例

主体、资源、权限相关的数据模型如下：

1. 主体(用户) --> 用户id、账号、密码……
2. 资源 --> 资源id、资源名称、访问地址……
3. 权限 --> 权限id、权限标识、权限名称、资源id……
4. 角色 --> 角色id、角色名称……
5. 角色和权限关系 --> 角色id、权限id……
6. 主体(用户)和角色关系 --> 用户id、角色id……

注：为了方便赋予用户权限，在中间使用角色表。角色表就好比是权限的打包体

上图是一个标准的授权数据模型，但在企业开发中将资源表和权限表合并成一种权限表：

• 权限表 --> 权限id、权限标识、权限名称、资源名称、资源访问地址……

合并后的数据模型关系图如下：

3. RBAC访问控制

RBAC是当前业界最广泛的授权解决方案，本质上它是一种思想任何编程语言都能实现

RBAC分为两种：

• 基于角色的访问控制(Role-Based Access Control)
• 基于资源的访问控制(Resource-Based Access Control)

3.1 基于角色的访问控制

    RBAC基于角色的访问控制是按照角色进行授权，角色是权限的封装，一个角色有多种权限，每一个主体可以赋予多个角色

例：主体用户的角色是运营总监，这个角色可以查询企业运营报表，查询员工工资信息等

根据判断逻辑，简单的授权代码可表示为：

if(主体.hasRole("运营总监角色id")){
   查询报表
}

如果上图中查询工资所需要的角色变化为总经理和部门经理也能查询，此就需要家多重判断

if(主体.hasRole("运营总监角色id") || 主体.hasRole("总经理角色id")){
   查询报表
}

注：根据上面的例子可知，在使用角色访问控制时，当需要修改角色的权限时就需要修改授权的相关代码，系统的可拓展性差

3.2 基于资源的访问控制

RBAC基于资源的访问控制是按照资源进行授权，每种资源的操作生成一种权限，在实际操作时判断是否有这种权限

例：主体用户查询公司运营报表，运营报表的操作需要运营权限

根据上图，简单的代码可为：

if(主体.hasRole("运营权限标识")){
    查询报表
}

只要有运营权限，无论是总经理、部门经理、总监都可以查询报表

注：系统设计时定义好查询工资的权限标识，即使查询工资所需要的角色变化为总经理也不需要修改授权代码，可拓展性较强