JSON Web Token(JWT)简介
2020-07-18 11:26:31 
阿炯
JSON WEB Token(JWT，读作 [/dʒɒt/])，是一种基于JSON的、用于在网络上声明某种主张的令牌(token)。是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准(RFC 7519)，该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。它为传统的session认证方式之外提供了另外一种可选的方法。
JWT定义了一种紧凑且独立的方式，可在各方之间作为JSON对象安全地传输信息。此信息可以通过数字签名进行验证和信任。JWT可以使用秘密(使用HMAC算法)或使用RSA或ECDSA的公钥/私钥对进行签名。虽然JWT可以加密以在各方之间提供保密，但只将专注于签名令牌。签名令牌可以验证其中包含的声明的完整性，而加密令牌则隐藏其他方的声明。当使用公钥/私钥对签署令牌时，签名还证明只有持有私钥的一方是签署私钥的一方。与单点登录的方式类似。
单点登录的机制简述如下：
用户认证：这一环节主要是用户向认证服务器发起认证请求，认证服务器给用户返回一个成功的令牌token，主要在认证服务器中完成，即图中的认证系统，注意认证系统只能有一个。
身份校验：这一环节是用户携带token去访问其他服务器时，在其他服务器中要对token的真伪进行检验，主要在资源服务器中完成，即下图中的应用系统2、3。
通俗来讲，JWT是一个含签名并携带用户相关信息的加密串，页面请求校验登录接口时，请求头中携带JWT串到后端服务，后端通过签名加密串匹配校验，保证信息未被篡改。校验通过则认为是可靠的请求，将正常返回数据。下面的情况下使用JWT比较适合：
1)、授权：这是最常见的使用场景，解决单点登录问题。因为JWT使用起来轻便，开销小，服务端不用记录用户状态信息(无状态)，所以使用比较广泛。
2)、信息交换：JWT是在各个服务之间安全传输信息的好方法。因为JWT可以签名，例如，使用公钥/私钥对儿 - 可以确定请求方是合法的。此外，由于使用标头和有效负载计算签名，还可以验证内容是否未被篡改。
JWT通常由三部分组成: 头信息(header), 消息体(payload)和签名(signature)，下面依次介绍这三个部分：
头部：主要设置一些规范信息，签名部分的编码格式就在头部中声明。
载荷：token中存放有效信息的部分，比如用户名，用户角色，过期时间等，但是不要放密码，会泄露！
签名：将头部与载荷分别采用base64编码后，用“.”相连，再加入盐，最后使用头部声明的编码类型进行编码，就得到了签名。
1、Header
Header 部分是一个 JSON 对象，描述 JWT 的元数据，通常是下面的样子。
{
"alg": "HS256",
"typ": "JWT"
}
上面代码中，alg属性表示签名的算法(algorithm)，默认是 HMAC SHA256(写成 HS256)；typ属性表示这个令牌(token)的类型(type)，JWT 令牌统一写为JWT。最后将上面的 JSON 对象使用 Base64URL 算法(详见后文)转成字符串。
2、Payload
Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据。JWT 规定了7个官方字段，供选用。
iss (issuer)：签发人
exp (expiration time)：过期时间
sub (subject)：主题
aud (audience)：受众
nbf (Not Before)：生效时间
iat (Issued At)：签发时间
jti (JWT ID)：编号
除了官方字段，你还可以在这个部分定义私有字段，下面就是一个例子。
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
注意，JWT 默认是不加密的，任何人都可以读到，所以不要把秘密信息放在这个部分。
这个 JSON 对象也要使用 Base64URL 算法转成字符串。
3、Signature
Signature 部分是对前两部分的签名，防止数据篡改。首先，需要指定一个密钥(secret)。这个密钥只有服务器才知道，不能泄露给用户。然后使用 Header 里面指定的签名算法(默认是 HMAC SHA256)，按照下面的公式产生签名。
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload),secret)
算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用"点"(.)分隔，就可以返回给用户。
4、Base64URL
前面提到，Header 和 Payload 串型化的算法是 Base64URL。这个算法跟 Base64 算法基本类似，但有一些小的不同。
JWT 作为一个令牌(token)，有些场合可能会放到 URL(比如 api.example.com/?token=xxx)。Base64 有三个字符+、/和=，在 URL 里面有特殊含义，所以要被替换掉：=被省略、+替换成-，/替换成_ 。这就是 Base64URL 算法。
头信息指定了该JWT使用的签名算法:
header = '{"alg":"HS256","typ":"JWT"}'
HS256 表示使用了 HMAC-SHA256 来生成签名。
消息体包含了JWT的意图：
payload = '{"loggedInAs":"admin","iat":1422779638}'//iat表示令牌生成的时间
未签名的令牌由base64url编码的头信息和消息体拼接而成(使用"."分隔)，签名则通过私有的key计算而成：
key = 'secretkey'
unsignedToken = encodeBase64(header) + '.' + encodeBase64(payload)
signature = HMAC-SHA256(key, unsignedToken)
最后在未签名的令牌尾部拼接上base64url编码的签名(同样使用"."分隔)就是JWT了：
token = encodeBase64(header) + '.' + encodeBase64(payload) + '.' + encodeBase64(signature)
# token看起来像这样: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI
JWT常常被用作保护服务端的资源(resource)，客户端通常将JWT通过HTTP的Authorization header发送给服务端，服务端使用自己保存的key计算、验证签名以判断该JWT是否可信：
Authorization: Bearer eyJhbGci*...<snip>...*yu5CSpyHI
JWT 的几个特点
(1)JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
(2)JWT 不加密的情况下，不能将秘密数据写入 JWT。
(3)JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。
(4)JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。
(5)JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
(6)为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。
基于session认证所显露的问题
Session：每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以方便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。
扩展性：用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上，这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力，这也意味着限制了应用的扩展能力。
CSRF：因为是基于cookie来进行用户识别的，cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。
基于Token的鉴权机制
类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。在流程上是这样的：
用户使用用户名密码来请求服务器
服务器进行验证用户的信息
服务器通过验证发送给用户一个token
客户端存储token，并在每次请求时附送上这个token值
服务端验证token值，并返回数据
这个token必须要在每次请求时传递给服务端，它应该保存在请求头里，另外服务端要支持CORS(跨来源资源共享)策略，一般在服务端需要这样做：Access-Control-Allow-Origin: *。
JWT生成token的安全性分析
从JWT生成的token组成上来看，要想避免token被伪造，主要就得看签名部分了，而签名部分又有三部分组成，其中头部和载荷的base64编码，几乎是透明的，毫无安全性可言，那么最终守护token安全的重担就落在了加入的盐上面了！试想：如果生成token所用的盐与解析token时加入的盐是一样的。岂不是类似于将防伪技术公开了？大家可以用这个盐来解析token，就能用来伪造token。这时我们就需要对盐采用非对称加密的方式进行加密，以达到生成token与校验token方所用的盐不一致的安全效果！
非对称加密RSA简介
基本原理：同时生成两把密钥：私钥和公钥，私钥隐秘保存，公钥可以下发给信任客户端
私钥加密，持有私钥或公钥才可以解密
公钥加密，持有私钥才可解密
优点：安全，难以破解
缺点：算法比较耗时，为了安全，可以接受
用户身份验证的令牌--Token
Token是什么？
所谓Token，其实就是服务端生成的一串加密字符串、以作客户端进行请求的一个“令牌”。当用户第一次使用账号密码成功进行登录后，服务器便生成一个Token及Token失效时间并将此返回给客户端，若成功登陆，以后客户端只需在有效时间内带上这个Token前来请求数据即可，无需再次带上用户名和密码。
拿实际过程举例，当下载QQ或微信后第一次用账号和密码成功登录后，Token就为我们免去了每次打开应用都要输入账号跟密码的过程。
为什么要使用Token？
为什么要使用Token？这个问题其实很好回答——因为它能解决一些问题！
当下用户对产品的使用体验要求在逐渐提高，从产品体验方面来讲，Token带来的体验更容易能让用户接受。
那么Token都可以解决哪些问题呢？
Token具有随机性、不可预测性、时效性、无状态、跨域等特点。
Token完全由应用管理，所以它可以避开同源策略。
Token可以避免CSRF攻击。
Token可以是无状态的，可以在多个服务间共享。
Token是在服务端产生的。如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回Token给前端，前端可以在每次请求的时候带上Token证明自己的合法地位。如果这个Token在服务端持久化(比如存入数据库)，那它就是一个永久的身份令牌。
当然说到这里大家可能会想到，用服务器的session_id存储到cookies中也能做到，为什么非要用Token呢？
网上有许多对比Token和session的文章，在此就不再赘述。如果是开发web应用的话，用两者都可以，但如果是开发API接口，前后端分离，最好使用Token，因为session+cookies是基于web的，但针对API接口可能会考虑到移动端，app是没有cookies和session的。
Token的生命周期
用户未登录
用户执行注册/登录
一旦基础数据校验成功，后端生成Token，并且Token包含此次注册/登录用户的用户名并通过JsonResponse返回给前端。
前端拿到返回的Token后，存入浏览器本地存储。
用户每次访问页面时
从本地存储中拿出Token
JS将Token放入request的Authorization头，发送http请求向后端索要数据。
服务器接到前端请求(当前URL加了loging_check,并且请求方法在methods参数中),进行校验。
从requestAuthorization头拿出Token。
校验
校验不通过，返回前端异常代码/校验通过，正常执行对应的视图函数。
前端一旦接到关于Token的异常码，则删除本地存储中的Token,且将用户转至登录界面。
如何设置Token的有效期？
其实Token作为一个概念模型，开发者完全可以针对自己开发的应用自定义Token，只要能做到不让不法分子钻系统漏洞即可。那么为Token设置有效期还有必要吗？对于这个问题，大家不妨先看两个例子：
例1：登录密码
登录密码一般要求定期改变密码，以防止泄漏，所以密码是有有效期的。
例2：安全证书
SSL安全证书都有有效期，目的是为了解决吊销的问题。所以无论是从安全的角度考虑，还是从吊销的角度考虑，Token都需要设有效期。那么，Token的有效期多长合适呢？
一般来说，基于系统安全的需要当然需要尽可能的短，但也不能短得离谱：如果在用户正常操作的过程中，Token过期失效要求重新登录，用户体验岂不是很糟糕？
为了解决在操作过程不让用户感到Token失效的问题，有一种方案是在服务器端保存Token状态，用户每次操作都会自动刷新(推迟)Token的过期时间。
如此操作会存在一个问题，即在前后端分离、单页App等情况下，每秒可能发起多次请求，如果每次都去刷新过期时间会产生非常大的代价，同样地，如果Token的过期时间被持久化到数据库或文件，代价就更大了。所以通常为了提升效率、减少消耗，会把Token的过期时保存在缓存或者内存中。
另一种方案是使用RefreshToken，它可以避免频繁的读写操作。
这种方案中，服务端无需刷新Token的过期时间，一旦Token过期，就反馈给前端，前端使用RefreshToken申请一个全新Token继续使用。服务端只需要在客户端请求更新Token的时候对RefreshToken的有效性进行一次检查，大大减少了更新有效期的操作，也就避免了频繁读写。
当然RefreshToken也是有有效期的，但是这个有效期就可以长一点了。使用 Token 和 Refresh Token 的时序图如下：
1)登录
2)业务请求
3)Token 过期，刷新 Token
本文总结自互联网，感谢众多网友。
JWT定义了一种紧凑且独立的方式，可在各方之间作为JSON对象安全地传输信息。此信息可以通过数字签名进行验证和信任。JWT可以使用秘密(使用HMAC算法)或使用RSA或ECDSA的公钥/私钥对进行签名。虽然JWT可以加密以在各方之间提供保密，但只将专注于签名令牌。签名令牌可以验证其中包含的声明的完整性，而加密令牌则隐藏其他方的声明。当使用公钥/私钥对签署令牌时，签名还证明只有持有私钥的一方是签署私钥的一方。与单点登录的方式类似。
单点登录的机制简述如下：
用户认证：这一环节主要是用户向认证服务器发起认证请求，认证服务器给用户返回一个成功的令牌token，主要在认证服务器中完成，即图中的认证系统，注意认证系统只能有一个。
身份校验：这一环节是用户携带token去访问其他服务器时，在其他服务器中要对token的真伪进行检验，主要在资源服务器中完成，即下图中的应用系统2、3。
通俗来讲，JWT是一个含签名并携带用户相关信息的加密串，页面请求校验登录接口时，请求头中携带JWT串到后端服务，后端通过签名加密串匹配校验，保证信息未被篡改。校验通过则认为是可靠的请求，将正常返回数据。下面的情况下使用JWT比较适合：
1)、授权：这是最常见的使用场景，解决单点登录问题。因为JWT使用起来轻便，开销小，服务端不用记录用户状态信息(无状态)，所以使用比较广泛。
2)、信息交换：JWT是在各个服务之间安全传输信息的好方法。因为JWT可以签名，例如，使用公钥/私钥对儿 - 可以确定请求方是合法的。此外，由于使用标头和有效负载计算签名，还可以验证内容是否未被篡改。
JWT通常由三部分组成: 头信息(header), 消息体(payload)和签名(signature)，下面依次介绍这三个部分：
头部：主要设置一些规范信息，签名部分的编码格式就在头部中声明。
载荷：token中存放有效信息的部分，比如用户名，用户角色，过期时间等，但是不要放密码，会泄露！
签名：将头部与载荷分别采用base64编码后，用“.”相连，再加入盐，最后使用头部声明的编码类型进行编码，就得到了签名。
1、Header
Header 部分是一个 JSON 对象，描述 JWT 的元数据，通常是下面的样子。
{
"alg": "HS256",
"typ": "JWT"
}
上面代码中，alg属性表示签名的算法(algorithm)，默认是 HMAC SHA256(写成 HS256)；typ属性表示这个令牌(token)的类型(type)，JWT 令牌统一写为JWT。最后将上面的 JSON 对象使用 Base64URL 算法(详见后文)转成字符串。
2、Payload
Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据。JWT 规定了7个官方字段，供选用。
iss (issuer)：签发人
exp (expiration time)：过期时间
sub (subject)：主题
aud (audience)：受众
nbf (Not Before)：生效时间
iat (Issued At)：签发时间
jti (JWT ID)：编号
除了官方字段，你还可以在这个部分定义私有字段，下面就是一个例子。
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
注意，JWT 默认是不加密的，任何人都可以读到，所以不要把秘密信息放在这个部分。
这个 JSON 对象也要使用 Base64URL 算法转成字符串。
3、Signature
Signature 部分是对前两部分的签名，防止数据篡改。首先，需要指定一个密钥(secret)。这个密钥只有服务器才知道，不能泄露给用户。然后使用 Header 里面指定的签名算法(默认是 HMAC SHA256)，按照下面的公式产生签名。
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload),secret)
算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用"点"(.)分隔，就可以返回给用户。
4、Base64URL
前面提到，Header 和 Payload 串型化的算法是 Base64URL。这个算法跟 Base64 算法基本类似，但有一些小的不同。
JWT 作为一个令牌(token)，有些场合可能会放到 URL(比如 api.example.com/?token=xxx)。Base64 有三个字符+、/和=，在 URL 里面有特殊含义，所以要被替换掉：=被省略、+替换成-，/替换成_ 。这就是 Base64URL 算法。
头信息指定了该JWT使用的签名算法:
header = '{"alg":"HS256","typ":"JWT"}'
HS256 表示使用了 HMAC-SHA256 来生成签名。
消息体包含了JWT的意图：
payload = '{"loggedInAs":"admin","iat":1422779638}'//iat表示令牌生成的时间
未签名的令牌由base64url编码的头信息和消息体拼接而成(使用"."分隔)，签名则通过私有的key计算而成：
key = 'secretkey'
unsignedToken = encodeBase64(header) + '.' + encodeBase64(payload)
signature = HMAC-SHA256(key, unsignedToken)
最后在未签名的令牌尾部拼接上base64url编码的签名(同样使用"."分隔)就是JWT了：
token = encodeBase64(header) + '.' + encodeBase64(payload) + '.' + encodeBase64(signature)
# token看起来像这样: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI
JWT常常被用作保护服务端的资源(resource)，客户端通常将JWT通过HTTP的Authorization header发送给服务端，服务端使用自己保存的key计算、验证签名以判断该JWT是否可信：
Authorization: Bearer eyJhbGci*...<snip>...*yu5CSpyHI
JWT 的几个特点
(1)JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
(2)JWT 不加密的情况下，不能将秘密数据写入 JWT。
(3)JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。
(4)JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。
(5)JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
(6)为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。
基于session认证所显露的问题
Session：每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以方便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。
扩展性：用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上，这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力，这也意味着限制了应用的扩展能力。
CSRF：因为是基于cookie来进行用户识别的，cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。
基于Token的鉴权机制
类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。在流程上是这样的：
用户使用用户名密码来请求服务器
服务器进行验证用户的信息
服务器通过验证发送给用户一个token
客户端存储token，并在每次请求时附送上这个token值
服务端验证token值，并返回数据
这个token必须要在每次请求时传递给服务端，它应该保存在请求头里，另外服务端要支持CORS(跨来源资源共享)策略，一般在服务端需要这样做：Access-Control-Allow-Origin: *。
JWT生成token的安全性分析
从JWT生成的token组成上来看，要想避免token被伪造，主要就得看签名部分了，而签名部分又有三部分组成，其中头部和载荷的base64编码，几乎是透明的，毫无安全性可言，那么最终守护token安全的重担就落在了加入的盐上面了！试想：如果生成token所用的盐与解析token时加入的盐是一样的。岂不是类似于将防伪技术公开了？大家可以用这个盐来解析token，就能用来伪造token。这时我们就需要对盐采用非对称加密的方式进行加密，以达到生成token与校验token方所用的盐不一致的安全效果！
非对称加密RSA简介
基本原理：同时生成两把密钥：私钥和公钥，私钥隐秘保存，公钥可以下发给信任客户端
私钥加密，持有私钥或公钥才可以解密
公钥加密，持有私钥才可解密
优点：安全，难以破解
缺点：算法比较耗时，为了安全，可以接受
用户身份验证的令牌--Token
Token是什么？
所谓Token，其实就是服务端生成的一串加密字符串、以作客户端进行请求的一个“令牌”。当用户第一次使用账号密码成功进行登录后，服务器便生成一个Token及Token失效时间并将此返回给客户端，若成功登陆，以后客户端只需在有效时间内带上这个Token前来请求数据即可，无需再次带上用户名和密码。
拿实际过程举例，当下载QQ或微信后第一次用账号和密码成功登录后，Token就为我们免去了每次打开应用都要输入账号跟密码的过程。
为什么要使用Token？
为什么要使用Token？这个问题其实很好回答——因为它能解决一些问题！
当下用户对产品的使用体验要求在逐渐提高，从产品体验方面来讲，Token带来的体验更容易能让用户接受。
那么Token都可以解决哪些问题呢？
Token具有随机性、不可预测性、时效性、无状态、跨域等特点。
Token完全由应用管理，所以它可以避开同源策略。
Token可以避免CSRF攻击。
Token可以是无状态的，可以在多个服务间共享。
Token是在服务端产生的。如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回Token给前端，前端可以在每次请求的时候带上Token证明自己的合法地位。如果这个Token在服务端持久化(比如存入数据库)，那它就是一个永久的身份令牌。
当然说到这里大家可能会想到，用服务器的session_id存储到cookies中也能做到，为什么非要用Token呢？
网上有许多对比Token和session的文章，在此就不再赘述。如果是开发web应用的话，用两者都可以，但如果是开发API接口，前后端分离，最好使用Token，因为session+cookies是基于web的，但针对API接口可能会考虑到移动端，app是没有cookies和session的。
Token的生命周期
用户未登录
用户执行注册/登录
一旦基础数据校验成功，后端生成Token，并且Token包含此次注册/登录用户的用户名并通过JsonResponse返回给前端。
前端拿到返回的Token后，存入浏览器本地存储。
用户每次访问页面时
从本地存储中拿出Token
JS将Token放入request的Authorization头，发送http请求向后端索要数据。
服务器接到前端请求(当前URL加了loging_check,并且请求方法在methods参数中),进行校验。
从requestAuthorization头拿出Token。
校验
校验不通过，返回前端异常代码/校验通过，正常执行对应的视图函数。
前端一旦接到关于Token的异常码，则删除本地存储中的Token,且将用户转至登录界面。
如何设置Token的有效期？
其实Token作为一个概念模型，开发者完全可以针对自己开发的应用自定义Token，只要能做到不让不法分子钻系统漏洞即可。那么为Token设置有效期还有必要吗？对于这个问题，大家不妨先看两个例子：
例1：登录密码
登录密码一般要求定期改变密码，以防止泄漏，所以密码是有有效期的。
例2：安全证书
SSL安全证书都有有效期，目的是为了解决吊销的问题。所以无论是从安全的角度考虑，还是从吊销的角度考虑，Token都需要设有效期。那么，Token的有效期多长合适呢？
一般来说，基于系统安全的需要当然需要尽可能的短，但也不能短得离谱：如果在用户正常操作的过程中，Token过期失效要求重新登录，用户体验岂不是很糟糕？
为了解决在操作过程不让用户感到Token失效的问题，有一种方案是在服务器端保存Token状态，用户每次操作都会自动刷新(推迟)Token的过期时间。
如此操作会存在一个问题，即在前后端分离、单页App等情况下，每秒可能发起多次请求，如果每次都去刷新过期时间会产生非常大的代价，同样地，如果Token的过期时间被持久化到数据库或文件，代价就更大了。所以通常为了提升效率、减少消耗，会把Token的过期时保存在缓存或者内存中。
另一种方案是使用RefreshToken，它可以避免频繁的读写操作。
这种方案中，服务端无需刷新Token的过期时间，一旦Token过期，就反馈给前端，前端使用RefreshToken申请一个全新Token继续使用。服务端只需要在客户端请求更新Token的时候对RefreshToken的有效性进行一次检查，大大减少了更新有效期的操作，也就避免了频繁读写。
当然RefreshToken也是有有效期的，但是这个有效期就可以长一点了。使用 Token 和 Refresh Token 的时序图如下：
1)登录
2)业务请求
3)Token 过期，刷新 Token
本文总结自互联网，感谢众多网友。