首先我们要清楚session与token的实现思想
session
思想
1、客户端用户名跟密码请求登录
2、服务端收到请求，去库验证用户名与密码
3、验证成功后，服务端种一个cookie或发一个字符到客户端，同时服务器保留一份session
4、客户端收到 响应 以后可以把收到的字符存到cookie
5、客户端每次向服务端请求资源的cookie会自动携带
6、服务端收到请求，然后去验证cookie和session，如果验证成功，就向客户端返回请求的库数据
Session存储位置: 服务器内存，磁盘，或者数据库里
Session存储内容: id,存储时间，用户名等说明一下登录的用户是谁
客户端携带 ： cookie自动带，localStorage手动带
token
思想
在服务端不需要存储用户的登录记录，全部发给客户端有客户端自己存(cookie,local)
1、客户端使用用户名跟密码请求登录
2、服务端收到请求，去验证用户名与密码
3、验证成功后，服务端会签发一个 Token（加了密的字符串），再把这个 Token 发送给客户端
4、客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
5、客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
6、服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据
session vs token
| session | token | |
|---|---|---|
| 服务端保存用户信息 | √ | × |
| 避免CSRF攻击 | × | √ |
| 安装性 | 一般 | 高 |
| 多服务器粘性问题 | 存在 | 不存在 |
多服务器粘性问题
当在应用中进行 session的读，写或者删除操作时，会有一个文件操作发生在操作系统的temp 文件夹下，至少在第一次时。假设有多台服务器并且 session 在第一台服务上创建。当你再次发送请求并且这个请求落在另一台服务器上，session 信息并不存在并且会获得一个“未认证”的响应。我知道，你可以通过一个粘性 session 解决这个问题。然而，在基于 token 的认证中，这个问题很自然就被解决了。没有粘性 session 的问题，因为在每个发送到服务器的请求中这个请求的 token 都会被拦截
CSRF
CSRF 全称 Cross-site request forgery, 通常缩写为CSRF 或者 XSRF, 中文名跨站请求伪造.是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。. CSRF 攻击手段是通过发起改变状态的请求, 而不是窃取用户的数据, 因为攻击者无法得到服务器返回的响应