Session认证

1、用户向服务器发送用户名和密码

2、服务器验证通过，在当前会话（session）中保存相关数据，比如用户角色、登录时间等

3、服务器给用户返回一个session_id，写入用户的cookie

4、用户随后的每一次请求，都会通过cookie，将session_id交给服务器

5、服务器验证session_id，根据session_id找到保存的相关数据，得知用户的身份

缺点：如果是服务器集群，或者是跨域的服务导向结构，就要求session数据共享，比如（多台服务器时，客户端发请求时随机分布在一台服务器上，当下一次发请求时可能被分布在另一台服务器上，这时候这台服务器没有上次请求的cookie或者session，此时有需要重新登录）

解决方案：1、将session数据持久化，写入数据库或别的持久层

​ 2、服务器不再保存session数据，所有数据都保存在客户端，每次请求都发回服务器，比如Token认证

Token认证

1、客户端使用用户名跟密码登录，服务端收到请求，验证用户名和密码

2、验证成功后，服务端会签发一个token并把这个token发送到客户端

3、客户端收到token以后，会把它存储起来，比如放在cookie或者localStorage

4、客户端每次向服务端请求资源的时候需要带着服务端签发的token

5、服务端收到请求，然后去验证客户、端请求里面带着的token，如果验证成功，就向客户端返回请求的数据

优点：1、基于token的用户认证是一种服务器端无状态的认证方式，服务端不用存放token数据

2、用解析token的计算时间换取session的存储空间，从而减轻服务器的压力，减少频繁的查询数据库

3、token完全由应用管理，所以它可以避开同源策略

​ oken机制通过在请求头中添加Token之类的凭证，在客户端和服务器之间建立了一个跨域通信的桥梁，从而避免了同源策略的限制。在使用Token进行身份验证时，请求头通常包括一个”Authorization”字段，包含了Token所代表的身份认证信息，服务器可以使用这个Token来识别请求的合法性。

4、避免CSRF攻击

session和token的区别

1、session是一个用户一个，token是一个客户端一个

2、session没有将数据传到浏览器，token将数据加密后传过去了

3、session_id是服务器自动生成的，token是程序员自己定义的

4、token不用查，token本身就是加密的用户信息，服务器拿到后解密就有了