JWT的基本组成结构

发布时间 2023-06-18 09:47:12作者: 小小俊少

JWT组成结构

1.令牌组成

  • 1.标头(Header)
  • 2.有效载荷(Payload)
  • 3.签名(Signature)
  • 因此,JWT通常如下所示:xxxxx.yyyyy.zzzzz Header.Payload.Signature

2. Header

  • 标头通常由两部分组成令牌的类型(即JWT)和所使用的签名算法,例如HMAC SHA256或RSA。它会使用 Base64 编码组成 JWT 结构的第一部分。

  • 注意:Base64是一种编码,也就是说,它是可以被翻译回原来的样子来的。它并不是一种加密过程。

// typ =》 type 类型,省略 e ,减小数据大小
// algorithm =》 算法
{
  "alg": "HS256",
  "typ": "JWT"
}

2. Payload 有效负载

  • 令牌的第二部分是有效负载,其中包含声明。声明是有关实体 ,用户相关信息,类似 principal

  • (通常是用户)和其他数据的声明。同样的,它会使用 Base64 编码组成 JWT 结构的第二部分

注意敏感信息不能放入 payload,比如 密码,因为保存在客户端,还是会有被窃取的风险的

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

3. Signature 签名

其实就是  算法 HS256(Base64(header + payload),secret私钥)=》Siganture签名,绝对不能泄露,不然的话,你的 token 就不安全了,会被攻击服务器

如果是公钥的话,算法 HS256(Base64(header + payload),随机盐salt + 公钥)=》Siganture签名, 重点就在 随机盐

  • 前面两部分都是使用 Base64 进行编码的,即前端可以解开知道里面的信息。Signature 需要使用编码后的 headerpayload 以及我们提供的一个密钥,然后使用 header 中指定的签名算法(默认HS256)进行签名。签名的作用是保证 JWT 没有被篡改过

  • 如:

    HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret);

JWT校验

如果,服务器通过前端传递的 JWT 的前两部分,headerpayload,通过 算法 HS256(Base64(header + payload),secret私钥) 计算出来的 Signature 签名和 前端传递的 JWTSignature 签名一致的话,就代表验证通过

私钥。只能保存在 安全的硬件设备、云服务提供商的密钥管理服务、本地计算机上的密钥库(做小项目的时候,通常直接生成放到 项目中)

签名目的
  • 最后一步签名的过程,实际上是对头部以及负载内容进行签名,防止内容被窜改如果有人对头部以及负载的内容解码之后进行修改,再进行编码,最后加上之前的签名组合形成新的JWT的话,那么服务器端会判断(通过算法和密钥计算)出新的头部和负载形成的签名和前端传递过来的JWT附带上的签名是不一样的。如果要对新的头部和负载进行签名,在不知道服务器加密时用的密钥的话,得出来的签名也是不一样的。
信息安全问题
  • 在这里大家一定会问一个问题:Base64是一种编码,是可逆的,那么我的信息不就被暴露了吗?
  • 是的。所以,在JWT中,不应该在负载里面加入任何敏感的数据。在上面的例子中,我们传输的是用户的User ID。这个值实际上不是什么敏感内容,一般情况下被知道也是安全的。但是像密码这样的内容就不能被放在JWT中了。如果将用户的密码放在了JWT中,那么怀有恶意的第 三方通过Base64解码就能很快地知道你的密码了。因此JWT适合用于向Web应用传递一些非敏感信息。JWT还经常用于设计用户认证和授权系统,甚至实现Web应用的单点登录。

4. 令牌样式

image-20230425003802801

三者放在一起
  • 输出是三个由点分隔的Base64-URL字符串,可以在HTML和HTTP环境中轻松传递这些字符串,与基于XML的标准(例如SAML)相比,它更紧凑。

  • 简洁(Compact)

    可以通过URL, POST 参数或者在 HTTP header 发送,因为数据量小,传输速度快

  • 自包含(Self-contained)

    负载中包含了所有用户所需要的信息,避免了多次查询数据库

image-20230425003924412