JWT概述以及Token刷新机制详解
作者：透明果冻
这篇文章主要介绍了JWT概述以及Token刷新机制,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
一、概述
什么是JWT，简单的说就是一个存储在请求头中的字符串，包含了用户信息和校验信息。较为正式一点的来说， JWT（JSON Web Token）是一种无状态的身份认证机制，通常用于前后端分离项目。
它具有以下特点：
- 无状态：JWT是基于客户端存储的，不会存储在服务端，减轻了服务端的存储压力
- 高性能：每次请求都会携带JWT，而不用查询数据库或缓存，就能完成身份认证
- 对于跨域友好：由于是通过HTTP请求进行传输，不存在跨域限制
二、JWT组成
JWT由三部分组成，各部分用.隔开。header.payload.signature。
- header（头部）：用于存储JWT类型和加密算法。
- payload（负载）：存储数据，如用户id，过期时间等。
- signature（签名）：由密钥（通常是一个对称密钥或者非对称密钥） 对前两部分利用某种特定的加密算法进行签名，防止篡改。
三、JWT认证
用户输入账号密码，经过服务端校验成功后，就会生成一个JWT，首先选择其加密算法类型，如 HS256，将这一部分内容放入头部中，然后在负载中放入用户id，过期时间等信息；然后会使用一个 密钥 对前两部分进行 HMAC-SHA256 签名，防止篡改。然后将JWT返回给客户端，客户端将其存储在本地缓存中。
以后的每次请求中，都带上该JWT。服务端从请求头请求头中获取该JWT，然后使用相同的密钥对其进行验证，若验证成功则获取负载中的信息，对其中的信息进行验证，一般是查询db，验证用户id的有效性。然后才对该请求进行放行。
四、与传统session相比较
JWT与传统session的区别：
- JWT是存储在客户端，服务端 通过请求头获取，而session通常是存储在服务端，一般通过查询缓存获取
- JWT更适合分布式项目，而session则需要使用共享方案来实现
- JWT容易被篡改，而session由于是存储在服务端，更安全
- 服务器不能更改JWT的过期时间和删除它，而对于session来说较为容易
五、对于token失效的解决策略
我们之前讨论的 JWT 认证 基本流程是：
- 用户登录后，服务器生成一个 Access Token（通常较短有效期，如 15 分钟），并返回给客户端。
- 客户端每次请求时都会携带 Access Token，服务器通过验证 Access Token 来确认用户身份。
但存在一定问题：
- Access Token 一旦过期，用户需要重新登录才能获取新的 Access Token。
- 频繁要求用户登录会影响用户体验，尤其是对于需要长时间使用的app
所以引入 Refresh Token机制来解决上述问题：
Refresh Token 是一个长期有效的 Token，一般有效期7-30天，它的作用是用来刷新已过期的 Access Token。
工作流程
用户登录：
- 用户提交用户名和密码给服务器。
- 服务器验证成功后，生成 Access Token 和 Refresh Token。
- Access Token 有较短的有效期（例如 15 分钟），而 Refresh Token 有较长的有效期（例如 7 天）。
Access Token 过期：
- 当 Access Token 过期时，客户端发送请求到服务器，携带过期的 Access Token和有效的 Refresh Token，这时候客户端不需要让用户重新登录，而是使用Refresh Token来向服务器请求刷新一个新的 Access Token。
- 服务器验证 Refresh Token，如果有效，则生成新的 Access Token 和新的 Refresh Token（防止Refresh Token被盗用）返回给客户端。
- 客户端用新的 Access Token 继续访问 API。
Token 刷新失败：
- 如果 Refresh Token 也过期，或者 Refresh Token 被篡改，服务器会要求用户重新登录。
注意：
- Refresh Token 本身不会直接用于访问 API，仅用于刷新 Access Token。
总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。