密码和证书等常见的身份认证手段仅仅用于登录系统时，当登录完成之后，不可能每次请求都去验证密码和账号，所以登陆成功之后需要有一个对用户透明的机制来进行验证，那就是session(同时session也要有保存用户状态的一个作用)

cookie-session机制

原理

• 第一次访问
  • 如果以前从来没有登录过某个网站，http头部中不会携带cookie。浏览器为登录后的用户生成一个session-id，并返回给浏览器，浏览器将这个session-id保存在客户端。
• 后序访问
  • 访问时会在自己的cookie中携带服务器给分配的session-id，服务器收到后根据这个session-id在自己的缓存中索引用户信息，并将保存的用户数据返回给客户端。
• 很久后的访问
  • cookie是有失效的，很久之后再次访问会重新生成性的session-id使原来的session-id失效。

sessionID最常见的做法是保存在cookie中，除此之外还可以保存在URL中，不过这样不是很安全，目前很多的手机浏览器都不支持cookie,在这种情况下只能保存在URL中。

弊端

• 服务器压力增大：通常session是存储在内存中的，每个用户通过认证之后都会将session数据保存在服务器的内存中，而当用户量增大时，服务器的压力增大。

有一种解决办法是把session放在cookie中加密好，当浏览器访问网页时，带上这个cookie,服务器端只要解密就可以得到用户的session。

• CSRF跨站伪造请求攻击：session是基于cookie进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击，cookie劫持https://blog.csdn.net/qq_39328436/article/details/114262076

• 扩展性不强：如果将来搭建了多个服务器，虽然每个服务器都执行的是同样的业务逻辑，但是session数据是保存在内存中的（不是共享的），用户第一次访问的是服务器1，当用户再次请求时可能访问的是另外一台服务器2，服务器2获取不到session信息，就判定用户没有登陆过。

token机制

在cookie-session机制中，最大的弊端就是服务器要存储session,token主要就是用来缓解这个矛盾的。

原理

客户端在第一次访问时，服务器给客户端颁发一个令牌（token），下次客户端再次访问时，携带着这个令牌，便完成了一次身份认证。

token验证的过程：

• 客户端使用用户名跟密码请求登录
• 服务端收到请求，去验证用户名与密码
• 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
• 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
• 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
• 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据

session VS token

1.session保存在服务器端，导致服务器压力增大，不利于服务器扩展。token保存在客户端，服务器用计算时间换取了存储空间。

2.token更加安全，请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)，因为token会被拼接在url中，难以伪造。