引言
前文介绍了 Session-Cookie 的认证过程，简单回顾下基本步骤：
- 客户端（浏览器）向服务器发送用户名和密码
- 服务器验证通过后，创建 Session 对象，在 Session 中保存该用户相关的数据，比如用户角色、登录时间等等
- 服务器向用户返回这个 Session 对象的唯一标识 SessionId，并写入客户端的 Cookie
- 客户端随后的每一次请求，都会通过 Cookie，将 SessionId 传回服务器
- 服务器收到 SessionId，并据此找到 Session 对象，由此获取到用户信息
这种方法的缺点就是分布式集群情况下无法保证每台服务器都拥有相同的 Session，上篇文章也简单介绍了几种 Session 如何在多个服务器之间共享的方法。
显然，Session 的维护给服务端造成了很大的困扰，有没有更好的方案，能不能直接不用 Session？
为此，Token 应运而生。
30s 图解 Token 认证
首先，什么是 Token？
简单来说，Token 其实就是一串字符串，一个令牌，客户端访问服务器时，验证通过后服务端会为其签发一张令牌，之后，客户端就可以携带这个令牌访问服务器，服务端只需要验证令牌的有效性即可。
一般来说，Token 的组成是这样的：
uid (用户唯一的身份标识) + time (当前时间的时间戳) + sign (签名，Token 的前几位以哈希算法压缩成的一定长度的十六进制字符串)
基于 token 的认证步骤如下图，配合文字食用：
1）客户端（浏览器）：用户向服务器发送登录信息（用户名和密码）来请求登录校验；
2）服务端：验证用户名密码等，验证成功后生成 token 并返回给前端，这个 token 就是之后鉴权的唯一凭证。服务端需要将这个 token 及其对应的用户信息存储在数据库或者缓存中；
3）客户端：将服务端返回的 token 存在 cookie 或者 localStorge 中，之后的每次请求之前，从 cookie 或者 localStorge 取出 token 将其设置进 HTTP Header 中（可以通过 HTTP 请求拦截器实现）；
4）服务端：服务端接收到来自客户端的请求，从 HTTP Header 中取出 token，去缓存或者数据库中进行验证（该 token 是否存在 / 根据该 token 能否找到对应的用户），如果验证通过则执行进一步的业务操作，如果不通过则拒绝执行。
附加阅读
Token 认证服务端代码
先来看登录，就是先判断用户名密码是否正确，如果正确，那么会生成并返回一个字符串做为 token（这里偷个懒就直接用 UUID 来生成了），并将其和用户信息（这里就简单的存了 username）一并存入到数据库 or 缓存中（这里采用 Redis，过期时间可自行配置）。
退出登录实质就是删除 Redis 中存储的 token，完整内容如下：
再来个拦截器，前端拿到后端返回的 token 后每次请求前都会在 HTTP header 中带上这个 token，服务端设置个拦截器取出 Header 中的token，然后去 Redis 中进行判断这个 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 并返回给前端，服务端需要将这两个 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
小伙伴们大家好呀，本文首发于公众号@飞天小牛肉，阿里云 & InfoQ 签约作者，分享大厂面试原创高质量题解、原创技术干货和成长经验。回复『
春秋招』我拉你进求职吹水交流群，回复『简历修改』免费获取简历修改服务，回复『Echo』免费获取社区项目手把手教程）收留 2023 秋招伤心人，秋招补录 & 春招强势开启，现在不投年后要被冲烂啦，信息汇总长期更新：小牛肉 x 互联网春招 & 秋招补录信息汇总