文章目录

• 前言
• 1. cookie
• 2. session
• 3. token
• • 3.1 为什么要使用token
  • 3.2 token详解

前言

cookie、session、token为了解决什么问题：

HTTP是一种无状态的协议，而服务器的业务必须是有状态的。
随着在线购物网站、需要登录的网站等等，面临的问题就是要管理会话。Session 、 Cookie、Token等就是来解决这个问题的机制。

鉴权流程图：

根据上图可以看到，从用户请求发起，到服务端完成操作，流程颇多，但是HTTP无状态，我们如何才能详细记录这些操作过程并加以严格的权限判断控制，接下来就开始今天的主题！

1. cookie

Cookie 诞生的最初目的是为了存储 web中的状态信息，方便服务器端使用。比如判断用户是否是第一次访问网站等问题。

cookie是保存在本地终端的数据。cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。

• cookie 是客户端技术，程序把每个用户的数据以 cookie 的形式写给用户各自的浏览器。当用户使用浏览器再去访问服务器中的web资源时，就会带着各自的数据去。这样，web资源处理的就是用户各自的数据了。
• cookie的处理：
  • 服务器向客户端发送cookie
  • 浏览器保存cookie
  • 之后每次http请求浏览器都会将cookie发送给服务器

Cookie干嘛用的？Cookie存在的价值

1. 会话状态管理（如用户登录状态、购物车、游戏分数、其它需要记录的信息）
2. 个性化设置（如用户自定义设置、主题等）
3. 精准广告。（平常浏览网页时有时会推出商品刚好是你最近浏览过，买过的类似东西，这些是通过cookie记录的。）

2. session

session从字面上讲，就是会话。这个就类似你和一个人交谈，你怎么知道当时和你交谈的是张三而不是李四呢？对方肯定有某种特征（长相等）表明他是张三；
session也是类似的道理，服务器要知道当前请求发给自己的是谁。为了做这种区分，服务器就是要给每个客户端分配不同的"身份标识"(session id)，然后客户端每次向服务器发请求的时候，都带上这个”身份标识“，服务器就知道这个请求来自与谁了。
至于客户端怎么保存这个”身份标识“，可以有很多方式，对于浏览器客户端，大家都采用cookie的方式。

session是服务端存储的一个对象，主要用来存储所有访问过该服务端的客户端的用户信息（也可以存储其他信息），从而实现保持用户会话状态。但是服务器重启时，内存会被销毁，存储的用户信息也就消失了。

不同的用户访问服务端的时候会在session对象中存储键值对，“键”用来存储开启这个用户信息的“钥匙”，在登录成功后，“钥匙”通过cookie返回给客户端，客户端存储为sessionId记录在cookie中。当客户端再次访问时，会默认携带cookie中的sessionId来实现会话机制。

理解一：

1. 浏览器第一次访问服务器，服务器会创建一个 session，并生成一个 sessionId

2. 将 sessionid 及对应的 session 分别作为 key 和 value 保存到缓存中，也可以持久化到数据库中

3. 服务器再把 sessionid，以 cookie 的形式发送给客户端

4. 浏览器下次再访问时，会直接带着 cookie 中的 sessionid。然后服务器根据 sessionid 找到对应的 session 进行匹配

理解二：

1. 用户向服务器发送用户名和密码
2. 服务器验证通过后，在当前对话(session)里面保存相关数据，比如用户角色、登录时间等
3. 服务器向用户返回一个session_id，写入用户的cookie
4. 用户随后的每一次请求，都会通过cookie，将session_id传回服务器
5. 服务器收到session_id，找到前期保存的数据，由此得知用户身份。

存在的问题----扩展性不好：

单机没有问题，但如果是服务器集群，或者是跨域的服务导向架构，就要求session数据共享，每台服务器都能够读取session。

另一种方案是服务器索性不保存session数据了，所有数据就保存在客户端，每次请求都发回服务器。

3. token

3.1 为什么要使用token

思考一下：服务器为什么要保存可恶的session，为什么不让每个客户端去保存。

但是如果不保存session id，怎么验证客户端发给服务器的session id的确是服务器生成的。
如果不去验证，服务器不知道客户端是不是合法登录的用户，就会有人伪造session id，为所欲为。

关键点是验证。

比如说，小F已经登录了系统，服务器给客户端发一个令牌(token)，里面包含了小F的user id，下一次小F再次通过http 请求访问服务器的时候，客户端把token通过http header带给服务器。

不过要是这样的话，就和session id没有区别，任何人都可以伪造。

服务器可以对数据进行签名，eg：用HMAC-SHA256 算法，加上一个只有服务器才知道的密钥，对数据做一个签名，把签名和数据一起作为token，由于密钥其他人不知道，就无法伪造token。

这个token 我不保存， 当小F把这个token 给我发过来的时候，我再用同样的HMAC-SHA256 算法和同样的密钥，对数据再计算一次签名， 和token 中的签名做个比较， 如果相同， 我就知道小F已经登录过了，并且可以直接取到小F的user id , 如果不相同， 数据部分肯定被人篡改过， 我就告诉发送者： 对不起，没有认证。

token中的数据是明文保存的，还是可以被别人看到的，但所以我不能在其中保存像密码这样的敏感信息。

当然， 如果一个人的token 被别人偷走了， 那我也没办法， 我也会认为小偷就是合法用户， 这其实和一个人的session id 被别人偷走是一样的。

这样一来， 我就不保存session id 了， 我只是生成token , 然后验证token ， 我用我的CPU计算时间获取了我的session 存储空间 ！

解除了session id这个负担， 可以说是无事一身轻， 我的机器集群现在可以轻松地做水平扩展， 用户访问量增大， 直接加机器就行。 这种无状态的感觉实在是太好了！

3.2 token详解

token的意思是“令牌”，是用户身份的验证方式，最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。还可以把不变的参数也放进token，避免多次查库。

1. 用户通过用户名和密码发送请求
2. 程序验证
3. 程序返回一个签名的token给客户端
4. 客户端存储token，并且每次用token发送请求
5. 服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码

token和session的区别：

Session是一种HTTP储存机制， 为无状态的HTTP提供持久机制;

Token就是令牌， 比如你授权(登录)一个程序时，它就是个依据，判断你是否已经授权该软件；

Session和Token并不矛盾，作为身份认证Token安全性比Session好，因为每一个请求都有签名还能防止监听以及重放攻击，而Session就必须依赖链路层来保障通讯安全了。如上所说，如果你需要实现有状态的回话，仍然可以增加Session来在服务端保存一些状态。