JWT原理分析 & 避坑指南

发布时间:2024-02-05 09:30:50
 

为什么会有JWT的出现?

首先不得不提到一个知识叫做跨域身份验证,JWT的出现就是为了更好的解决这个问题,但是在没有JWT的时候,我们一般怎么做呢?一般使用Cookie和Session,流程大体如下所示:

  1. 用户向服务端发送用户名和密码进行验证
  2. 服务端验证之后,相关数据(如用户角色、登录时间等信息)会保存在当前的Session中
  3. 服务端向用户返回一个唯一的session_id,同时在响应请求中设置cookie,属性名为jessionid
  4. 客户端收到之后会保存jessionid,再次请求的时候,会在header中设置,服务端可以从请求头中获取
  5. 服务端验证获取到的sessionid是否存在,即可验证是否是同一用户

使用Cookie和Session这种模式最大的问题之一就是它不支持横向扩展,也就是不支持分布式架构,如果当前只有一台服务器,那就没什么问题,但是在当下的时代,一台服务器往往是不够的,现在绝大多数都是服务器集群。如果是服务器集群,那么在负载均衡的时候就不能保证每次都发送到同一台服务器上,这样的话也就不能验证用户的身份了,但是这对用户是不友好的,用户是感知不到自己的请求发送到了别的服务器上的。

所以这个时候就提出来了让session落库,当一个请求发过来之后,验证服务从数据库去验证用户身份,这样就能让各个服务器正确的验证用户身份信息,但是这样做,依赖性太强,如果这个session数据库挂了,那么整个认证系统都会崩溃。

JWT的面世

因为Cookie和Session的局限性,所有有人提出只让客户端存储数据,服务端不保存任何会话数据,每个请求都被发送回服务器,JWT就出现了。

下面放一张JWT官网的一张图,描述的是JWT的认证过程,可以先看看这张图,有个印象:

下面简单讲讲JWT的概念:

JWT是Json Web Token的缩写,它将用户信息加密到Token中,服务器不保存任何的用户信息。服务器通过使用保存的密钥验证Token的正确性,只要正确就通过验证。

上面可能很难理解,把它日常化一下就是在没有网络的年代,部门A要申请部门B的某个机器使用权,部门A肯定要先老大打报告,写申请,最后老大签字同意,部门A再拿着这个带有老大签字的这个申请报告去找部门B,部门B才能同意部门A使用,这就是JWT的流程。

JWT的数据结构

JWT总共包含了三个部分:Header头部、Payload负载、Signature签名。这三部分共同生成Token,三部分之间用“.”做分割

JWT 头部

JWT的头部是一个描述JWT元数据的JSON对象,如下所示:

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

其中的alg:表示的是签名使用的算法,默认为HMAC SHA256(写为HS256),typ:表示的是令牌的类型,JWT的令牌统一写为JWT。

这样的一个Json数据,还需要使用Base64 URL算法将其转为字符串保存。

JWT 负载

负载部分就是JWT的主体内容,同样的也是一个Json对象,它包含了需要传递的数据,但是不能传递敏感数据,因为这部分数据别人也是可以拿到并且解密的。

JWT指定有七个默认字段供选择:

  1. iss:发行人
  2. exp:到期时间
  3. sub:主题
  4. aud:用户
  5. nbf:在此之前不可用
  6. iat:发布时间
  7. jti:JWT ID 用于标识该 JWT

除了默认字段外,我们还可以自定义字段,如下所示:

同样,这部分数据依然是使用Base 64 URL算法转换为字符串加密。

JWT 签名

签名部分是对上面两部分的数据签名,通过指定的算法(在JWT头部指定的算法)生成哈希来确保数据不会被篡改。

一般流程如下:

  1. 在服务器中保存了一个密码(secret),这个密码仅仅保存在服务器中,不对用户开放。
  2. 使用JWT头部指定的签名算法以及服务器中保存的密码(secret)来生成对应的签名
  3. 在计算出签名之后,JWT头、负载、签名,三部分组成一个字符串,每个部分以“.”进行分割,构成JWT对象

JWT的认证流程

  1. 客户端发送信息给服务端,让其进行验证
  2. 服务端验证成功后,返回给客户端一个JWT
  3. 客户端将JWT保存在Cookie或放入HTTP请求的Header Authorization字段中(推荐放在这)
  4. 此后客户端请求的时候都带着JWT去请求服务端,服务端对JWT再进行验证

JWT的缺陷

  1. JWT最大的缺陷就是服务器不会保存会话状态,所以使用期间不能取消令牌或者更改令牌的权限,一旦JWT签发,在有效期内将会一直有效。
  2. 由于JWT不加密,所以JWT不能用来传递敏感数据
  3. 它有着更大的空间占用
  4. 很难应对过期的数据,由于无法废除掉已经颁布的令牌,在令牌过期之前,只能忍受过期的数据

总结

  • 在Web应用中,不能把JWT当作Session使用,绝大多数情况下,传统的cookie-session机制工作得更好
  • JWT适合一次性的命令认证,颁发一个有效期极短的JWT,即使暴露了危险也很小,由于每次操作都会生成新的JWT,因此也没必要保存JWT,真正实现无状态。

 
上一篇 布隆过滤器
下一篇 返回列表

文章素材均来源于网络,如有侵权,请联系管理员删除。

标签: Java教程Java基础Java编程技巧面试题Java面试题