- 用户输入用户名和密码并提交
- 服务器端验证用户发来的密码。
- 如果密码正确，则把用户信息存在缓存中(redis)中，并生成一个sessionID,以key value的形式存在缓存中，将sessionID放在cookie中，返回cookie给客户端。
- 用户再次再登录的时候，就将cookie带到请求中，服务端拿到cookie里面的sessionID,在缓存中查找并比对，通过这个sessionID查找用户信息，找到了则返回登录成功的消息，没找到则返回错误消息。
由服务器产生内容，浏览器收到请求后保存在本地；当浏览器再次访问时，浏览器会自动带上cookie，这样服务器就能通过cookie的内容来判断这个是“谁”了。
cookie虽然在一定程度上解决了“保持状态”的需求，但是由于cookie本身最大支持4096字节，以及cookie本身保存在客户端，可能被拦截或窃取，因此就需要有一种新的东西，它能支持更多的字节，并且他保存在服务器，有较高的安全性。这就是session。
问题来了，基于http协议的无状态特征，服务器根本就不知道访问者是“谁”。那么上述的cookie就起到桥接的作用。
我们可以给每个客户端的cookie分配一个唯一的id，这样用户在访问时，通过cookie，服务器就知道来的人是“谁”。然后我们再根据不同的cookie的id，在服务器上保存一段时间的私密资料，如“账号密码”等等。
总结而言：cookie弥补了http无状态的不足，让服务器知道来的人是“谁”；但是cookie以文本的形式保存在本地，自身安全性较差；所以我们就通过cookie识别不同的用户，对应的在session里保存私密的信息以及超过4096字节的文本。
- 用户首次登录，将输入的账号和密码提交给服务器。
- 服务器对输入内容进行校验，若账号和密码匹配则验证通过，登录成功，并生成一个token值，将其保存到数据库，并返回给客户端。
- 客户端拿到返回的token值将其保存在本地（如cookie/local storage），作为公共参数，以后每次请求服务器时都携带该token（放在响应头里），提交给服务器进行校验。
- 服务器接收到请求后，首先验证是否携带token，若携带则取出请求头里的token值与数据库存储的token进行匹配校验，若token值相同则登录成功，且当前正处于登录状态，此时正常返回数据，让app显示数据；若不存在或两个值不一致，则说明原来的登录已经失效，此时返回错误状态码，提示用户跳转至登录界面重新登录
注意：用户每进行一次登录，登录成功后服务器都会更新一个token新值返回给客户端
https://blog.csdn.net/u014322206/article/details/85089481
① token可以存储在任何位置（比如cookie或local storage）
② token更容易跨域
③ token过期时可以通过刷新token，让用户一直保持有效登录
④ 如果api在不同终端上，token更方便安全
1、为什么要使用session
因为http本身是无状态协议，无法确定你的本次请求和上次请求是不是你发送的。如果要进行类似论坛登陆相关的操作，就实现不了了。
2、Session 生成方式
浏览器第一次访问服务器，服务器会创建一个session，然后同时为该session生成一个唯一的会话的key,也就是sessionid，然后，将sessionid及对应的session分别作为key和value保存到缓存中，也可以持久化到数据库中，然后服务器再把sessionid，以cookie的形式发送给客户端。这样浏览器下次再访问时，会直接带着cookie中的sessionid。然后服务器根据sessionid找到对应的session进行匹配；
1、为什么要使用token
token在服务器是可以不需要存储用户的信息的，而token的传递方式也不限于cookie传递，可以保存在响应报文或者请求报文的报文头部中
2、token的生成方式
浏览器第一次访问服务器，根据传过来的唯一标识userId，服务端会通过一些算法，如常用的HMAC-SHA256算法，然后加一个密钥，生成一个token，然后通过BASE64编码一下之后将这个token发送给客户端；客户端将token保存起来，下次请求时，带着token，服务器收到请求后，然后会用相同的算法和密钥去验证token，如果通过，执行业务操作，不通过，返回不通过信息；
区别：
Session 需要保存在服务器端，
Token 不需要保存在服务器端