HTTP 身份验证

HTTP 身份验证

HTTP 提供一个用于权限控制和认证的通用框架。最常用的HTTP认证方案是HTTP Basic authentication。本页介绍了通用的HTTP认证框架以及展示如何通过HTTP Basic authentication来限制权限访问您的服务器。

通用的 HTTP 认证框架

RFC 7235 定义了一个 HTTP 身份验证框架，服务器可以用来针对客户端的请求发送 challenge （质询信息），客户端则可以用来提供身份验证凭证。质询与应答的工作流程如下：服务器端向客户端返回 401（Unauthorized，未被授权的） 状态码，并在 WWW-Authenticate 首部提供如何进行验证的信息，其中至少包含有一种质询方式。之后有意向证明自己身份的客户端可以在新的请求中添加 Authorization 首部字段进行验证，字段值为身份验证凭证信息。通常客户端会弹出一个密码框让用户填写，然后发送包含有恰当的 Authorization 首部的请求。

在上图所示的基本身份验证过程中，信息交换须通过 HTTPS(TLS) 连接来保证安全。

Basic access authentication 基本认证

在HTTP中，基本认证（英语：Basic access authentication）是允许http用户代理（如：网页浏览器）在请求时，提供 用户名 和 密码 的一种方式。

在进行基本认证的过程里，请求的HTTP头字段会包含Authorization字段，形式如下： Authorization: Basic <凭证>，该凭证是用户和密码的组和的base64编码。

最初，基本认证是定义在HTTP 1.0规范（RFC 1945）中，后续的有关安全的信息可以在HTTP 1.1规范（RFC 2616）和HTTP认证规范（RFC 2617）中找到。于1999年 RFC 2617 过期，于2015年的 RFC 7617 重新被定义。

Digest access authentication 摘要认证

摘要访问认证是一种协议规定的Web服务器用来同网页浏览器进行认证信息协商的方法。它在密码发出前，先对其应用哈希函数，这相对于HTTP基本认证发送明文而言，更安全。

从技术上讲，摘要认证是使用随机数来阻止进行密码分析的MD5加密哈希函数应用。它使用HTTP协议。

WWW-Authenticate

客户应该在Authorization头中提供什么类型的授权信息？在包含401（Unauthorized）状态行的应答中这个头是必需的。例如，response.setHeader(“WWW-Authenticate”, “BASIC realm=＼“executives＼”")。 注意Servlet一般不进行这方面的处理，而是让Web服务器的专门机制来控制受密码保护页面的访问（例如.htaccess）。

Authorization

HTTP协议中的 Authorization 请求消息头含有服务器用于验证用户代理身份的凭证，通常会在服务器返回401 Unauthorized 状态码以及WWW-Authenticate 消息头之后在后续请求中发送此消息头。

1

Authorization: <type> <credentials>

Basic RFC 7617, base64-encoded credentials.

Bearer RFC 6750, bearer tokens to access OAuth 2.0-protected resources

Digest RFC 7616. Firefox 93 and later support SHA-256 encryption. Previous versions only support MD5 hashing.

HTTP/1.1 默认采用持续连接（Connection: keep-alive），能很好地配合代理服务器工作。还支持以管道方式在同时发送多个请求，以便降低线路负载，提高传输速度。

• HTTP/2相比HTTP/1.1的修改并不会破坏现有程序的工作，但是新的程序可以借由新特性得到更好的速度。
• HTTP/2保留了HTTP/1.1的大部分语义，例如请求方法、状态码乃至URI和绝大多数HTTP头字段一致。而HTTP/2采用了新的方法来编码、传输客户端和服务器之间的数据。

安全认证方案

HTTP 基本认证

HTTP Basic Authentication（HTTP 基本认证）是 HTTP 1.0 提出的一种认证机制，这个想必大家都很熟悉了，我不再赘述。HTTP 基本认证的过程如下：

1. 客户端发送 HTTP Request 给服务器。
2. 因为 Request 中没有包含 Authorization header，服务器会返回一个 401 Unauthozied 给客户端，并且在 Response 的 Header “WWW-Authenticate” 中添加信息。
3. 客户端把用户名和密码用 BASE64 加密后，放在 Authorization Header 中发送给服务器， 认证成功。
4. 服务器将 Authorization Header 中的用户名密码取出，进行验证， 如果验证通过，将根据请求，发送资源给客户端。

基于 Session 的认证

基于 Session 的认证应该是最常用的一种认证机制了。用户登录认证成功后，将用户相关数据存储到 Session 中，单体应用架构中，默认 Session 会存储在应用服务器中，并且将 Session ID 返回到客户端，存储在浏览器的 Cookie 中。

但是在分布式架构下，Session 存放于某个具体的应用服务器中自然就无法满足使用了，简单的可以通过 Session 复制或者 Session 粘制的方案来解决。

Session 复制依赖于应用服务器，需要应用服务器有 Session 复制能力，不过现在大部分应用服务器如 Tomcat、JBoss、WebSphere 等都已经提供了这个能力。

除此之外，Session 复制的一大缺陷在于当节点数比较多时，大量的 Session 数据复制会占用较多网络资源。Session 粘滞是通过负载均衡器，将统一用户的请求都分发到固定的服务器节点上，这样就保证了对某一用户而言，Session 数据始终是正确的。不过这种方案依赖于负载均衡器，并且只能满足水平扩展的集群场景，无法满足应用分割后的分布式场景。

在微服务架构下，每个微服务拆分的粒度会很细，并且不只有用户和微服务打交道，更多还有微服务间的调用。这个时候上述两个方案都无法满足，就要求必须要将 Session 从应用服务器中剥离出来，存放在外部进行集中管理。可以是数据库，也可以是分布式缓存，如 Memchached、Redis 等。这正是 David Borsos 建议的第二种方案，分布式 Session 方案。

基于 Token 的认证

随着 Restful API、微服务的兴起，基于 Token 的认证现在已经越来越普遍。Token 和 Session ID 不同，并非只是一个 key。Token 一般会包含用户的相关信息，通过验证 Token 就可以完成身份校验。像 Twitter、微信、QQ、GitHub 等公有服务的 API 都是基于这种方式进行认证的，一些开发框架如 OpenStack、Kubernetes 内部 API 调用也是基于 Token 的认证。基于 Token 认证的一个典型流程如下：

1. 用户输入登录信息（或者调用 Token 接口，传入用户信息），发送到身份认证服务进行认证（身份认证服务可以和服务端在一起，也可以分离，看微服务拆分情况了）。
2. 身份验证服务验证登录信息是否正确，返回接口（一般接口中会包含用户基础信息、权限范围、有效时间等信息），客户端存储接口，可以存储在 Session 或者数据库中。
3. 用户将 Token 放在 HTTP 请求头中，发起相关 API 调用。
4. 被调用的微服务，验证 Token 权限。
5. 服务端返回相关资源和数据。

基于 Token 认证的好处如下：

1. 服务端无状态：Token 机制在服务端不需要存储 session 信息，因为 Token 自身包含了所有用户的相关信息。
2. 性能较好，因为在验证 Token 时不用再去访问数据库或者远程服务进行权限校验，自然可以提升不少性能。
3. 支持移动设备。
4. 支持跨程序调用，Cookie 是不允许垮域访问的，而 Token 则不存在这个问题。

• 引用类型的token(OAuth 2.0),不包含任何用户信息
• 自包含token(JWT)，包含用户信息,但不要在里面存储一些敏感的信息

Spring Security OAuth2

默认的端点 URL：

• /oauth/authorize：授权端点
• /oauth/token：令牌端点
• /oauth/confirm_access：用户确认授权提交端点
• /oauth/error：授权服务错误信息端点
• /oauth/check_token：用于资源服务访问的令牌解析端点
• /oauth/token_key：提供公有密匙的端点，如果你使用 JWT 令牌的话

初始化 OAuth2 相关表

MySQL 数据库，默认建表语句中主键为 VARCHAR(256)，这超过了最大的主键长度，请手动修改为 128，并用 BLOB 替换语句中的 LONGVARBINARY 类型

在表 oauth_client_details 中增加一条客户端配置记录，需要设置的字段如下：

• client_id：客户端标识
• client_secret：客户端安全码，此处不能是明文，需要加密
• scope：客户端授权范围
• authorized_grant_types：客户端授权类型
• web_server_redirect_uri：服务器回调地址

使用 BCryptPasswordEncoder 为客户端安全码加密，代码如下：

1

System.out.println(new BCryptPasswordEncoder().encode("secret"));

RBAC

RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。

RBAC其实是一种分析模型，主要分为：

• 基本模型RBAC0（Core RBAC）
• 角色分层模型RBAC1（Hierarchal RBAC）
• 角色限制模型RBAC2（Constraint RBAC）
• 统一模型RBAC3（Combines RBAC）

RBAC0定义了能构成RBAC控制系统的最小的元素集合，RBAC0由四部分构成：

• 用户（User）
• 角色（Role）
• 会话（Session）
• 许可（Pemission）

其中许可又包括“操作”和“控制对象”其中许可被赋予角色，而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的许可。会话是动态的概念，用户必须通过会话才可以设置角色，是用户与激活的角色之间的映射关系。

RBAC1，它是RBAC角色的分层模型，RBAC1建立在RBAC0基础之上，在角色中引入了继承的概念，有了继承那么角色就有了上下级或者等级关系

RBAC2，它是RBAC的约束模型，RBAC2也是建立的RBAC0的基础之上的，在RBAC0基础上假如了约束的概念，主要引入了静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。

SSD是用户和角色的指派阶段加入的，主要是对用户和角色有如下约束:

• 互斥角色：同一个用户在两个互斥角色中只能选择一个
• 基数约束：一个用户拥有的角色是有限的，一个角色拥有的许可也是有限的
• 先决条件约束：用户想要获得高级角色，首先必须拥有低级角色

DSD是会话和角色之间的约束，可以动态的约束用户拥有的角色，如一个用户可以拥有两个角色，但是运行时只能激活一个角色。

RBAC3，它是RBAC1与RBAC2合集，所以RBAC3是既有角色分层又有约束的一种模型

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

CREATE TABLE `tb_permission` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `parent_id` bigint(20) DEFAULT NULL COMMENT '父权限',
  `name` varchar(64) NOT NULL COMMENT '权限名称',
  `enname` varchar(64) NOT NULL COMMENT '权限英文名称',
  `url` varchar(255) NOT NULL COMMENT '授权路径',
  `description` varchar(200) DEFAULT NULL COMMENT '备注',
  `created` datetime NOT NULL,
  `updated` datetime NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=37 DEFAULT CHARSET=utf8 COMMENT='权限表';

CREATE TABLE `tb_role` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `parent_id` bigint(20) DEFAULT NULL COMMENT '父角色',
  `name` varchar(64) NOT NULL COMMENT '角色名称',
  `enname` varchar(64) NOT NULL COMMENT '角色英文名称',
  `description` varchar(200) DEFAULT NULL COMMENT '备注',
  `created` datetime NOT NULL,
  `updated` datetime NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=37 DEFAULT CHARSET=utf8 COMMENT='角色表';

CREATE TABLE `tb_role_permission` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `role_id` bigint(20) NOT NULL COMMENT '角色 ID',
  `permission_id` bigint(20) NOT NULL COMMENT '权限 ID',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=37 DEFAULT CHARSET=utf8 COMMENT='角色权限表';

CREATE TABLE `tb_user` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `username` varchar(50) NOT NULL COMMENT '用户名',
  `password` varchar(64) NOT NULL COMMENT '密码，加密存储',
  `phone` varchar(20) DEFAULT NULL COMMENT '注册手机号',
  `email` varchar(50) DEFAULT NULL COMMENT '注册邮箱',
  `created` datetime NOT NULL,
  `updated` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `username` (`username`) USING BTREE,
  UNIQUE KEY `phone` (`phone`) USING BTREE,
  UNIQUE KEY `email` (`email`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=37 DEFAULT CHARSET=utf8 COMMENT='用户表';

CREATE TABLE `tb_user_role` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `user_id` bigint(20) NOT NULL COMMENT '用户 ID',
  `role_id` bigint(20) NOT NULL COMMENT '角色 ID',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=37 DEFAULT CHARSET=utf8 COMMENT='用户角色表';