在Web开发领域，相信大家对于 Cookie 和 Session 都很熟悉，Cookie 和 Session 都是会话保持技术的解决方案。随着技术的发展，Token 机制出现在我们面前，不过很多开发者对于 Token 和 Cookie、Session 的区别及使用场景分辨不清。
session 和 cookie
一、什么是 session 和 cookie
- 首先要知道HTTP请求是无状态的，也就是不知道这一次的请求和上一次请求是否有关系，比如我们登录一个系统的时候，验证用户名密码之后，打开系统各个页面的时候就不需要再进行登录操作了，直到我们主动退出登录或超时退出登录；这里为了避免访问每个都登录一下，就要用到 session、cookie；
- cookie 是在客户端(浏览器)保存用户信息的一种机制；而且每种浏览器存储大小会有一些差异，一般不超过4KB；
- session是在服务端保存，可以用于记录客户状态，比如我们经常会用 session 保存客户的基本信息、权限信息等；用户第一次登录之后，服务器就会创建一个 session，浏览器再次访问时，只需要从该 session 中查找该客户的信息就可以了。
二、Cookie和Session的用途
- 要知道我们访问网站都是通过HTTP协议或HTTPS协议来完成的，HTTP协议它本身是无状态的协议（即：服务器无法分辨哪些请求是来源于同个客户）。而业务层面会涉及到客户端与服务器端的交互（同网站下多个页面间能共享数据），此时服务器端必须要保持会话状态，这样才能进行用户身份的鉴别。
- 由于HTTP无状态的特性，如果要实话客户端和服务器端的会话保持，那就需要其它机制来实现，于是Cookie和Session应运而生。
- 通常情况下，Session和Cookie是搭配在一起使用的。
Token
一、为什么会产生Token？
在这里会有个问题，服务器要保存所有用户的 session 信息，开销会很大，如果在分布式的架构下，就需要考虑 session 共享的问题，需要做额外的设计和开发，例如把 session 中的信息保存到 Redis 中进行共享；所以因为这个原因，有人考虑这些信息是否可以让客户端保存，可以保存到任何地方，并且保证其安全性，于是就有了Token。
二、什么是Token？
- Token是服务端生成的一串字符串，可以看做客户端进行请求的一个令牌。
- 当客户端第一次访问服务端，服务端会根据传过来的唯一标识userId，运用一些加密算法，生成一个Token，客户端下次请求时，只需要带上Token，服务器收到请求后，会验证这个Token。
- 有些公司会建设统一登录系统（单点登录），客户端先去这个系统获取Token，验证通过再拿着这些Token去访问其他系统；API Gateway也可以提供类似的功能，我们公司就是这样，客户端接入的时候，先向网关获取Token，验证通过了才能访问被授权的接口，并且一段时间后要重新或者Token。
- Token俗称为“令牌”，它的构成是：
- uid：用户唯一身份标识；
- timestamp：当前时间戳；
- sign：签名字符串，防止第三方伪造数据；签名密钥是存储在服务器端的，其它人无法知道；
- 其它附加参数。
三、基于Token的认证流程
- 客户端使用用户名、密码做身份验证；
- 服务端收到请求后进行身份验证(也可能是统一登录平台、网关)；
- 验证成功后，服务端会签发一个Token返回给客户端；
- 客户端收到Token以后可以把它存储起来（可以放在）；每次向服务端发送请求的时候，都要带着Token；
- Token会有过期时间，过期后需要重新进行验证；
- 服务端收到请求，会验证客户端请求里面的Token，验证成功，才会响应客户端的请求；
总结
- cookie：
- 保存在浏览器中，有大小限制，有状态；
- 由于存放在客户端，所以是不安全的，人为可以清除；
- cookie有过期时间设定，如果不设置过期时间，说明这个cookie就是当前浏览器的会话时间，浏览器关了，cookie 就存在了。如果有过期时间，cookie就会存储到硬盘上，浏览器关闭不影响cookie。下次打开浏览器，cookie还存在；
- cookie有大小的限制，4KB。
- session：保存在服务器中，服务器有资源开销，分布式、跨系统不好实现；
- Token：客户端可以将Token保存到任何地方，无限制，无状态，利于分布式部署。