Cookie，Session，Token

一、HTTP协议是无状态的

何为无状态：服务器不会记录用户的浏览记录，每次请求都是一个新的HTTP协议，就是请求加响应。不用记录谁刚刚发了HTTP请求，每次请求都是全新的。

二、管理会话

随着网络的发展，交互式网站例如需要登录的网站的兴起，服务器就面临一个问题，如何管理回话，如何记住那些人登录过系统，哪些人往自己的购物车中放商品，简单地说就是如何区分不同的用户

三、cookie

cookie 是一个非常具体的东西，指的就是浏览器里面能永久存储的一种数据。跟服务器没啥关系，仅仅是浏览器实现的一种数据存储功能。
cookie由服务器生成，发送给浏览器，浏览器把cookie以KV形式存储到某个目录下的文本文件中，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间。所以每个域的cookie数量是有限制的。

客户端设置
客户端可以设置cookie的一下选项: expires, domain, path, secure(只有在https协议的网页中, 客户端设置secure类型cookie才能生效), 但无法设置httpOnly选项
服务端设置
不管你是请求一个资源文件(如html/js/css/图片), 还是发送一个ajax请求, 服务端都会返回response.而response header中有一项叫set-cookie, 是服务端专门用来设置cookie的;

1.一个set-cookie只能设置一个cookie, 当你想设置多个, 需要添加同样多的set-cookie
2.服务端可以设置cookie的所有选项: expires, domain, path, secure, HttpOnly

Cookie，SessionStorage，LocalStorage

四、session

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

流程：

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

session和cookies的区别：

Cookie是客户端技术，程序把每个用户的数据以cookie的形式写给用户各自的浏览器。当用户使用浏览器再去访问服务器中的web资源时，就会带着各自的数据去。这样，web资源处理的就是用户各自的数据了。

Session是服务器端技术，利用这个技术，服务器在运行时可以为每一个用户的浏览器创建一个其独享的session对象，由于session为用户浏览器独享，所以用户在访问服务器的web资源时，可以把各自的数据放在各自的session中，当用户再去访问服务器中的其它web资源时，其它web资源再从用户各自的session中取出数据为用户服务。而由于不知道哪个用户对应哪个session，所以又引入了cookies来记录客户端和session的映射关系(jsessionId)

session存在的问题（扩展性不好）
单机当然没问题， 如果是服务器集群，或者是跨域的服务导向架构，这就要求session数据共享，每台服务器都能够读取session。
举例来说， A网站和B网站是同一家公司的关联服务。现在要求，用户只要在其中一个网站登录，再访问另一个网站就会自动登录，请问怎么实现？这个问题就是如何实现单点登录的问题

Nginx ip_hash 策略，服务端使用 Nginx 代理，每个请求按访问 IP 的 hash 分配，这样来自同一 IP 固定访问一个后台服务器，避免了在服务器 A 创建 Session，第二次分发到服务器 B 的现象。
Session复制：任何一个服务器上的 Session 发生改变（增删改），该节点会把这个 Session的所有内容序列化，然后广播给所有其它节点。
共享Session：将Session Id
集中存储到一个地方，所有的机器都来访问这个地方的数据。这种方案的优点是架构清晰，缺点是工程量比较大。另外，持久层万一挂了，就会单点失败；

对比

Servlet容器提供了Session机制以跟踪用户；

默认的Session机制是以Cookie形式实现的，Cookie名称为JSESSIONID；

通过读写Cookie可以在客户端设置用户偏好等。例如生效的路径范围，有效期等

另一种方案是服务器索性不保存session数据了，所有数据就保存在客户端，每次请求都发回服务器。这种方案就是接下来要介绍的基于Token的验证;

五、Token

流程：

1.用户通过用户名和密码发送请求
2.程序验证
3.程序返回一个签名的token给客户端
4.客户端储存token, 并且每次用每次发送请求
5.服务端验证Token并返回数据

这个方式的技术其实很早就已经有很多实现了，而且还有现成的标准可用，其中的一个标准就是JWT

六、JWT(JSON Web Token)

数据结构
实际的JWT大概就像下面这样：

JSON Web Tokens由dot（.）分隔的三个部分组成，它们是：

1.Header（头部）
2.Payload（负载）
3.signature（签名）

因此，JWT通常如下(xxxxx.yyyyy.zzzz)展示：

Header（头部）

//Header 是一个 JSON 对象
{"alg": "HS256", // 表示签名的算法，默认是 HMAC SHA256（写成 HS256）"typ": "JWT"  // 表示Token的类型，JWT 令牌统一写为JWT
}

Payload（负载）

//Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据
{// 7个官方字段"iss": "a.com", // issuer：签发人"exp": "1d", // expiration time： 过期时间"sub": "test", // subject: 主题"aud": "xxx", // audience： 受众"nbf": "xxx", // Not Before：生效时间"iat": "xxx", // Issued At： 签发时间"jti": "1111", // JWT ID：编号// 可以定义私有字段"name": "John Doe","admin": true
}

JWT 默认是不加密的，任何人都可以读到，所以不要把秘密信息放在这个部分。

Signature（签名）

Signature 是对前两部分的签名，防止数据被篡改。
首先，需要指定一个密钥(secret)。这个密钥只有服务器才知道，不能泄露给用户。然后，使用Header里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

复制代码算出签名后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用"点"（.）分隔，就可以返回给用户。

JWT = Base64(Header) + "." + Base64(Payload) + "." + $Signature

如何保证安全？
发送JWT要使用HTTPS；不使用HTTPS发送的时候，JWT里不要写入秘密数据JWT的payload中要设置expire时间

使用方式
客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。此后，客户端每次与服务端通信，都要带上这个JWT。你可以把它放在Cookie里面自动发送，但是这样不能跨域，所以更好的做法是放在HTTP请求的头信息 Authorization 字段里面。

Authorization: Bearer <token>

复制代码另一种做法是:

跨域的时候， JWT就放在POST请求的数据体里。

JWT 的作用
JWT最开始的初衷是为了实现授权和身份认证作用的，可以实现无状态，分布式的Web应用授权。大致实现的流程如下:

客户端需要携带用户名/密码等可证明身份的的内容去授权服务器获取JWT信息；
每次服务都携带该Token内容与Web服务器进行交互，由业务服务器来验证Token是否是授权发放的有效Token，来验证当前业务是否请求合法。

这里需要注意：不是每次请求都要申请一次Token，这是需要注意，如果不是对于安全性要求的情况，不建议每次都申请，因为会增加业务耗时；比如只在登陆时申请，然后使用JWT的过期时间或其他手段来保证JWT的有效性。

七、Acesss Token，Refresh Token

JWT最大的优势是服务器不再需要存储Session，使得服务器认证鉴权业务可以方便扩展。这也是JWT最大的缺点，由于服务器不需要存储Session状态，因此使用过程中无法废弃某个Token，或者更改Token的权限。也就是说一旦JWT签发了，到期之前就会始终有效。
我们可以基于上面提到的问题做一些改进。
前面讲的Token，都是Acesss Token，也就是访问资源接口时所需要的Token，还有另外一种Token，Refresh Token。一般情况下，Refresh Token的有效期会比较长。而Access Token的有效期比较短，当Acesss Token由于过期而失效时，使用Refresh Token就可以获取到新的Token，如果Refresh Token也失效了，用户就只能重新登录了。Refresh Token及过期时间是存储在服务器的数据库中，只有在申请新的Acesss Token时才会验证，不会对业务接口响应时间造成影响，也不需要向Session一样一直保持在内存中以应对大量的请求。