# 前后端分离的token问题

token:jwt,Json Web Token,一个被被签名后的字符串，被修改后能被发现的字符串！下称token均指该字符串。

token是自包含(负载中已经包含了用户信息或其他信息)、被签名的。任何人对token的修改会使之失效(服务器根据负载中信息，去验证签名是否正确，所以负载被修改或签名被修改都会导致失效)。

# Cookie

古早时期，网页就是一个 URL，只是一个地址，任何人都可以访问。

/a

/b

如果想 特定URI如 /b 只能某些人(如张三)访问呢？只能通过这种方式(暂不考虑ip认证等其他方式)：给张三一个用户名和密码，访问时先去登录页面登录，把用户名、密码提交给Server，Server判断用户名和密码正确，然后在这个请求过程中返回某种类似通行证的东西给Browser，Browser把这个通行证保存，下次访问这个网页(Server)时带上这个通行证Server就能确定访问用户了。
 

上面的通行证就是Cookie。

所以Http协议制定了Cookie机制，浏览器和服务器中的Http协议实现者也都完全支持了cookie。
 

cookie由服务器签发，交给浏览器保存、维护(到期后不再随HTTP请求提交)。

服务器需要确定cookie是否有效。方式有

1. 随机产生一段字符串，服务器保存一份(有人称保存该字符串的容器为Session)，浏览器提交过来时，查找服务器(Session中)是否有保存

2. cookie值放token字符串。

# 可以不用cookie

网页越来越复杂，比如跨域访问某些资源、前后台分离开发或部署时也会跨域，因为token大多被存放在localStorage里，所以请求发出方可以很轻松的获取、存放、发送请求时带上该token。

所以，当静态资源全部开放并且这些静态资源不需要使用cookie鉴权时，或者没有网页，只有客户端来调用API时，可以完全抛弃cookie。

所有认证信息在使用axios、fetch时手动指定认证信息(token)。

# 何时离不开cookie

静态页面需要认证，

静态页面需要确认请求来源，需要根据来源确定用户时，就必须使用cookie，因为cookie是浏览器自动带到所有请求上的。

# token有效期和重签发

token存在有效期，在构造token时即确定并写死，无法更改。

## 过期

cookie中过期，浏览器直接把本地的cookie删了。

localStorage中过期？

1 负载中带有有效期，发出请求时检查 或者，

2 token中未携带有效期时，直接发给Server，过期时响应特定状态码(如401)，再清除
 

## 重签发

Server拿到请求，发现token将要过期 --11. 新的token写到cookie中，并且cookie有效期和新token保持一致。

2. 若不使用cookie，指定响应码，axios收到该响应码时更新token，新token在当前响应体中带过来。或者调用个新的接口来响应新的token，再更新localStorage中的token。

## 废弃token

token一经签发，在指定的有效期内都是一段"有效的"字符串，服务端没办法直接判断该token是否以废弃。

可以这样，把要废弃的token保存在redis、mysql，Map等容器中，生命设置到token原生命周期。当请求过来时先查一下带来的token有没有被废弃，再决定响应码。
 

# 前台(浏览器)和客户端

使用Cookie时，有效期由Server指定，Browser只能主动调用注销接口让Server来设置Cookie的有效期为0使之失效。http响应回到浏览器时，浏览器更新cookie有效期，失效。

Token存在localStorage中时，前台主动废弃可以直接删掉token。