昨天发了篇 Token 认证的文章并同步到了博客园，收到个评论

我寻思着我不就是这么写的吗，检查一看，顿时惊出一身汗：

上图框出来的部分就是错误部分，事实上 Token 机制和 Session-Cookie 机制最大的区别就在于，后者需要在服务端存储 Session 对象，而前者的 Token 不需要在服务端进行存储，而是分散给每个客户端自行存储，大大缓解了服务端的压力。

怪我脑抽了，公众号还只能修改 20 个字，所以第一时间把文章删除了（估计有些小伙伴已经看到了），今天修改出来重新发下，哭死，如果能让大伙儿对 Token 有更深的印象那勉强算个将功补过吧

引言

前文介绍了 Session-Cookie 的认证过程，简单回顾下基本步骤：

1. 客户端（浏览器）向服务器发送用户名和密码
2. 服务器验证通过后，创建 Session 对象，在 Session 中保存该用户相关的数据，比如用户角色、登录时间等等
3. 服务器向用户返回这个 Session 对象的唯一标识 SessionId，并写入客户端的 Cookie
4. 客户端随后的每一次请求，都会通过 Cookie，将 SessionId 传回服务器
5. 服务器收到 SessionId，并据此找到 Session 对象，由此获取到用户信息

这种方法的缺点就是分布式集群情况下无法保证每台服务器都拥有相同的 Session，上篇文章也简单介绍了几种 Session 如何在多个服务器之间共享的方法。

显然，Session 的维护给服务端造成了极大的压力和困扰，有没有更好的方案，能不能直接不用 Session？

为此，Token 应运而生。

30s 图解 Token 认证

首先，什么是 Token？

简单来说，Token 其实就是一串字符串，一个令牌，客户端访问服务器时，验证通过后服务端会根据设定好的规则为其签发一张令牌，之后，客户端就可以携带这个令牌访问服务器，服务端只需要根据规则验证令牌的有效性即可。

一般来说，Token 的组成是这样的：

uid (用户唯一的身份标识) + time (当前时间的时间戳) + sign (签名，Token 的前几位以哈希算法压缩成的一定长度的十六进制字符串)

基于 Token 的认证步骤如下图，配合文字食用：

1）客户端（浏览器）：用户向服务器发送登录信息（用户名和密码）来请求登录校验；

2）服务端：验证用户名密码等，验证成功后生成 token 并返回给前端，这个 token 就是之后鉴权的唯一凭证；

3）客户端：将服务端返回的 token 存在 cookie 或者 localStorge 中，之后的每次请求之前，从 cookie 或者 localStorge 取出 token 将其设置进 HTTP Header 中（可以通过 HTTP 请求拦截器实现）；

4）服务端：服务端接收到来自客户端的请求，从 HTTP Header 中取出 token，并根据规则对 token 进行校验，如果验证通过则执行进一步的业务操作，如果不通过则拒绝执行。

附加阅读

Refresh Token

一般来说，为了安全起见，防止 token 被攻击者盗用，token 的有效期不会设置的太长，这样就会由于 token 过期导致用户需要重新登录从而生成新的 token。

如何才能做到不需要用户去频繁的登录呢，Refresh Token 机制出现了。

我们把之前的那个 Token 称之为 Access Token，业务接口用这个 Access Token 进行认证鉴权

而 Refresh Token 呢，就是一个专门用来在 Access Token 过期后重新获取新的 Access Token 的 Token

Refresh Token 的过期时间设置的长一点比如一两个月，Access Token 的过期时间设置短一点比如一周，这样可以缩短 Access Token 的过期时间保证安全，同时又不会因为频繁过期重新要求用户登录

具体认证步骤如下图，配合文字食用：

1）客户端（浏览器）：用户向服务器发送登录信息（用户名和密码）来请求登录校验；

2）服务端：验证用户名密码等，验证成功后生成 Access Token 和 Refresh Token 并返回给客户端；

3）客户端：将服务端返回的 Access Token 和 Refresh Token 存在 cookie 或者 localStorge 中，之后的每次请求之前，从 cookie 或者 localStorge 取出 Access Token 将其设置进 HTTP Header 中（可以通过 HTTP 请求拦截器实现）；

4）服务端：

• 验证 Access Token 有效：正常返回数据
• 验证 Access Token 过期：拒绝请求
• 客户端：重新发起请求，在 HTTP Header 中携带 Refresh Token 发送给服务端
• 服务端：验证客户端传来的 Refresh Token ，验证成功后生成新的 Access Token 并返回给客户端
• 客户端：获得服务端返回的新的 Access Token，重新发起请求并携带新的 Access Token

如何理解 Refresh Token 的必要性，或者说为什么使用 Refresh Token 能够更安全？

• Access Token 每次访问都要带着，因此更容易被盗取
• 而 Refresh Token 客户端获取到之后就保存起来，Access Token 失效之后，才会用到 Refresh Token，所以粗略来说 Refresh Token 只会在网络上传输两次，一次是你获取的时候，一次是你使用的时候（从上图可以看出来），因此 Refresh Token 被盗的风险远远小于 Access Token