1. 基本概念

1.1 什么是认证

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

系统为什么要认证？认证是为了保护系统的隐私数据与资源，用户的身份合法方可访问该系统的资源。

1.2 什么是会话

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

基于session的认证方式如下图：
它的交互流程是，用户认证成功后，在服务端生成用户相关的数据保存在session中（当前会话）中，发给客户端对应的session_id存放到cookie中，这样用户请求时带上session_id就可以验证服务器端是否存在session数据，以完成用户的合法校验，当用户退出系统或session过期销毁时，客户端的session_id也就无效了。

基于session的认证方式

基于token的认证方式如下图：
它的交互流程是，用户认证成功后，服务端生成一个token发给客户端，客户端可以放到cookie或localStorage等存储中，每次请求时带上token，服务端收到token通过验证后即可确认用户身份信息。

基于token的认证方式

基于session的认证方式由Servlet规范定制，服务端要存储session信息需要占用内存资源，客户端需要支持cookie；基于token的方式则一般不需要服务端存储token，并且不限制客户端的存储方式。如今移动互联网时代更多类型的客户端需要接入系统，系统多事采用前后端分离的架构进行实现，所以基于token的方式更为适合。

1.3 授权的数据模型

如何进行授权即如何对用户访问资源进行控制，首先需要学习授权相关的数据模型。
授权可简单理解为你Who对What(Which)进行How操作，包括如下：

• Who：即主体（Subject），主体一般是指用户，也可以是程序，需要访问系统中的资源。
• What：即资源（Resource），如系统菜单、页面、按钮、代码方法、系统商品信息、系统订单信息等。系统菜单、页面、按钮、代码方法等都属于系统功能资源，对于web系统每个功能资源通常对应一个URL；系统商品信息、系统订单信息都属于实体资源（数据资源），实体资源由资源类型和资源实例组成，比如商品信息为资源类型，商品编号为001的商品为资源实例。
• How：权限/许可（Permission），规定了用户对资源的操作许可，权限离开资源没有意义，如用户查询权限、用户添加权限、某个代码方法的调用权限、编号为001的用户的修改权限等，通过权限可知用户对那些资源都有哪些操作许可。

主体、权限、资源关系如下图：

主体、权限、资源关系

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

• 主体（用户id、账号、账号、密码、...）
• 资源（资源id、资源名称、访问地址、...）
• 权限（权限id、权限标识、权限名称、资源id、...）
• 角色（角色id、角色名称、...）
• 角色和权限关系（角色id、权限id、...）
• 主体（用户）和角色关系（用户id、角色id、...）

主体（用户）、资源、权限关系如下图：

主体（用户）、资源、权限关系

通常企业开发中将资源和权限表合并为一张权限表，如下：
资源（资源id、资源名称、访问地址、...）
权限（权限id、权限标识、权限名称、资源id、...）
合并为：
权限（权限id、权限标识、权限名称、资源名称、资源访问地址、...）

修改后的数据模型之前的关系如下图：

修改后的数据模型

1.4 RBAC

1.4.1 基于角色的访问控制

RBAC基于角色的访问控制（Role-Based Access Control）是按角色进行授权，比如：主体的角色为总经理可以查询企业运营报表，查询员工工资信息等，访问控制流程如下：

基于角色的访问控制（RBAC）流程

基于上图中的控制逻辑，伪代码如下：

if (主体.hasRole("总经理角色id")) {
  // 查询工资
}

如果上图中查询工资所需要的角色变化为总经理和部门经理，此时就需要修改判断逻辑为“判断用户的角色是否为总经理或者部门经理”，如下：

if (主体.hasRole("总经理角色id") || 主体.hasRole("部门经理角色id")) {
  // 查询工资
}

根据上边的例子可以发现，当需要修改角色的权限时就需要修改授权的相关代码，系统可扩展性差。

1.4.2 基于资源的访问控制

RBAC基于资源的访问控制（Resource-Based Access Control）是按资源（或权限）进行授权，比如：用户必须具有查询工资权限才可以查询员工工资信息等，访问控制流程如下：

基于资源的访问控制（RBAC）流程

基于上图中的控制逻辑，伪代码如下：

if (主体.hasPermission("查询工资权限标识")) {
  // 查询工资
}

优点：系统设计定义好查询工资的权限标识，即使查询工资所需要的角色变化为总经理和部门经理也不需要修改授权代码，系统可扩展性强。