关于JWT

最新推荐文章于 2025-05-21 10:31:28 发布

原创最新推荐文章于 2025-05-21 10:31:28 发布 · 892 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#restful #json #前端

智能陪护项目总结专栏收录该内容

3 篇文章

订阅专栏

JWT（JSON Web Token）是一种轻量级的身份验证标准，常用于跨域认证和信息传递。它通过将用户信息编码为一个字符串，包含头部、负载和签名三部分，确保数据的安全性和完整性。JWT解决了传统session认证在分布式系统、移动端和跨域访问中的问题，具有无状态、可跨域、节省服务器资源等优势。常见的签名算法包括HMAC、RSA和ECDSA。JWT认证流程涉及用户登录、token签发、验证及请求携带等步骤，广泛应用于现代Web和API身份验证。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

本文借鉴JWT详解

什么是JWT?

在介绍JWT之前，我们先来回顾一下token进行用户验证单的流程：
1.客户端使用用户名和密码请求登录
2.服务端收到请求，验证用户名和密码
3.验证成功后，服务端会签发一个token，在把这个token返回给客户端
4.客户端收到token后可以把他存储起来，比如放到cookie中
5.客户端每次向服务器请求资源时，需要携带服务端签发的token，可以在cookie或者header中携带
6.服务端收到请求之后，去验证客户端请求里面带着的token，如果验证成功，就向客户端返回请求数据。

这种基于token的认证方式相比于传统的session认证方式更加节约服务器资源，并且对移动端和分布式非常的友好。其优点如下：

支持跨域访问，cookie默认是无法跨域的，而token由于没有用到cookie（前提是将token放到请求头中），所以跨域后不会存在信息丢失问题。
无状态，token机制在服务端不需要存储session信息，因为token自身包含了所有登录用户信息，所以可以减轻服务端压力。
更适合移动端，当客户端不是浏览器平台的时候，cookie是不被支持的，此时采用token会方便很多。

而JWT就是上述流程中token的一种具体实现方式，其全称是JSON Web Token,通俗的来说，JWT本身就是一个字符串，他是将用户信息保存到一个JSON字符串中，然后进行编码后得到一个JWT token，并且这个JWT token带有签名信息，接收后可以校验是否被篡改。JWT的认证流程如下：

1.首先，前端通过Web表单将自己的用户名和密码发送到后端的接口，这个过程一般是一个post请求。建议的方式是通过，建议加密传输，避免敏感信息泄露
2.后端核对用户名和密码成功后，将包含用户信息的数据作为JWT 的PayLoad，将其与JWT Header分别进行Base64编码拼接后签名，形成一个JWT Token，形成的JWT Token就是一个如同lll.zzz.xxx字符串。
3.后端将JWT Token字符串作为登录成功的结果返回给前端。前端可以将返回的结果保存在浏览器中，退出登录时删除保存的JWT Token即可。
4.前端在每次请求时将JWT Token放入HTTP请求头中的Authorization属性中。
5.后端检查前端传过来的JWT Token，验证其有效性，比如检查签名是否正确，是佛过期，token的接收方是否自己等等。
6.验证通过后，后端解析出JWT Token中包含的用户信息，进行其他逻辑操作（一般是根据用户信息得到权限等），返回结果

在这里插入图片描述

为什么要用JWT

传统Session认证的弊端

我们知道Http本身是一种无状态的协议，这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，认证通过后的HTTP协议不会记录下认证后的状态，那么下一次请求的时候，用户还要再进行一次认证，因为根据Http协议，我们并不知道是哪个用户发出的请求，所以为了让我们的应用能识别哪个用户发出的请求，我们只能在用户首次登录成功后，在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为cookie，以便下次请求的时候发送给我们的应用，这样我们的应用就能识别请求来自哪个用户了，这是传统的基于session认证的过程。
在这里插入图片描述
然而，传统的session认证有如下的问题：

每个用户的登录信息都会保存在服务器的session中，随着用户的增多，服务器开销会明显增大。
由于session是存在服务器的物理内存中，所以在分布式系统中，这种方式将会失效。
对于非浏览器的客户端、手机移动端等不使用，因为session依赖于cookie，而移动端没有cookie。
因为session认证的本质基于cookie，所以如果cookie被截获，用户很容易收到跨域请求伪造攻击。并且如果浏览器禁用了cookie，这种方式也会失效。
在前后端分离的系统中更加不适用，后端部署复杂，前端发送的请求往往经过多个中间件到达后端，cookie中关于session的信息会转发多次
由于基于cookie，而cookie默认无法跨域，所以session的认证也无法跨域，对单点登录不适用。

JWT认证的优势

简洁，JWT Token数据量小，传输速度很快
因为JWT Token是以JSON加密形式保存在客户端的，所以JWT是跨语言的，原则上任何web形式都支持
不需要在服务端保存会话信息，也就是说不依赖cookie和session，所以没有了传统session认证的弊端，特别适用于分布式微服务。
可以跨域，token认证，token可以被认证在客户端的任意位置的内存中，不一定是cookie，所以不依赖cookie，可以实现跨域访问。

JWT结构

JWT由三部分组成：标头（Header）、有效载荷（Payload）和签名（Signature）。在传输的时候，会将JWT的三部分分别进行Base64编码后用.进行连接最终传输的字符串。

header

JWT头是一个描述JWT元数据的JSON对象，alg属性表示签名使用的算法，默认为HMAC SHA256;typ属性表示令牌的类型，JWT令牌统一写为JWT。最后，使用Base64 URL算法将上述JSON对象转换为字符串保存。

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

有效载荷部门，是JWT的主体内容部分，也是一个JSON对象，包含需传递的数据，JWT指定七个默认字段供选择。

iss：发行人
exp：到期时间
sub：主题
aud：用户
nbf：在此之前不可用
iat：发布时间
jti：JWT ID用于标识该JWT

除了上边七个默认字段，我们还可以自定义私有字段，一般会把包含用户信息的数据放到Payload中，如下例：

{
  "sub": "1234567890",
  "name": "Helen",
  "admin": true
}

Signature

签名哈希部分是对上面两部分数据签名，需要使用Base64编码后的header和payload数据，通过指定的算法生成哈希，以确保数据不会篡改。首先，需要指定一个密钥（secret）。该密码仅仅保存在服务器中，并且不能向用户公开，然后，使用header中指定的签名算法（默认情况下为HMAC SHA256）生成签名。

在计算出签名哈希后，JWT头，有效载荷和签名哈希的三个部分组合成一个字符串，每个部分用.分隔，就构成整个JWT对象.
在这里插入图片描述

注意JWT 每部分的作用，在服务端接收到客户端发送过来的JWT Token之后：
1.header和payload可以直接利用base64解码出原文，从header中获取哈希签名的算法，从payload中获取有效数据
2.signature由于使用了不可逆的加密算法，无法解码出原文，他的作用是校验token有没有被篡改。服务端获取header中的加密算法后，利用该算法加上secretKey对header、payload进行加密，比对加密后的数据和客户端发送过来的是否一致。注意secretKey只能保存在服务端，而且对于不同的加密算法其含义有所不同。

JWT的种类

nonsecure JWT：未经过签名，不安全的JWT
JWS：经过签名的JWT
JWE：payload部分经过加密的JWT

nonsecure JWT

未经过签名，不安全的JWT，其 header部分没有指定签名算法。

{
  "alg": "none",
  "typ": "JWT"
}

JWS

JWS,也就是 JWT Signature，其结构就是在之前nonsecure JWT的基础上，在头部声明签名算法，并在最后添加上签名。创建签名是保证jwt不能被他人随意篡改。我们通常使用的JWT一般都是JWS。
为了完成签名，处理用到header信息和payload信息外，还需要算法的密钥，也就是secretKey，加密的算法一般由两种：