转载

JWT 也不是万能的呀，入坑需谨慎！

本文地址： http://1t.click/QEh

越来越多的开发者开始学习 JWT 技术并在实际项目中运用 JWT 来保护应用安全。一时间，JWT 技术风光无限，很多公司的应用程序也开始使用 JWT（Json Web Token）来管理用户会话信息。本文将从 JWT 的基本原理出发，分析在使用 JWT 构建基于 Tok en 的身份验证系统时需要谨慎对待的细节。

任何技术框架都有自身的局限性，不可能一劳永逸，JWT 也不例外。接下来，将从JWT 的概念，基本原理和适用范围来剖析为什么说JWT 不是银弹，需要谨慎处理。

众所周知，如果我们的账户信息（用户名和密码）泄露，存储在服务器上的隐私数据将受到毁灭性的打击，如果是管理员的账户信息泄露，系统还有被攻击的危险。那么，JWT 的信息发生泄露，会带来什么样的影响？该如何防范？这将是本文重点阐述的内容。

1、什么是Token

Token(令牌)通常是指 Security Token(安全令牌)，可以分为 Hardware Token(硬件令牌)，Authentication Token(授权令牌)，USB Token(USB令牌)，Cryptographic Token(加密令牌)，Virtual Token(虚拟令牌)和 Key Fob(钥匙卡)。其主要作用是验证身份的合法性，以允许计算机系统的用户可以操作系统资源。生活中常见的令牌如：登录密码，指纹，声纹，门禁卡，银行电子卡等。Token 的主要目的是为计算机系统提供一个可以识别用户的任意数值，例如 “token123” 这样的明文字符串，或者像 “41ea873f-3a4d-57c8-1e38-ef74f31015af” 之类的加密字符。

由于篇幅关系，Token就了解到这里。接下来将聊聊有关JWT(JSON Web Token)的原理。

2、什么是JSON Web Token

JSON Web Token(JWT)是一个基于 RFC 7519 的开放数据标准，它定义了一种宽松且紧凑的数据组合方式，使用 JSON 对象在各应用之间传输加密信息。该 JSON 对象可以通过数字签名进行鉴签和校验，一般地，JWT 可以采用 HMAC 算法，RSA 或者 ECDSA 的公钥/私钥对数据进行签名操作。

一个JWT 通常有 HEADER (头)，PAYLOAD (有效载荷)和 SIGNATURE (签名)三个部分组成，三者之间使用“.”链接，格式如下：

下面是的字符串是一个JWT的实际案例：

注意三者之间有一个点号(“.”)相连

为了更直观的了解JWT的创建过程和使用方式，我们通过一个简单的例子来演示这两个过程。关于 Spring Boot 整合 JWT 大家可以参考一个案例学会Spring Security 中使用 JWT!

3、如何创建JWT?

JWT通常由“标头.有效载荷.签名”的格式组成。其中，标头用于存储有关如何计算JWT签名的信息，如对象类型，签名算法等。下面是JWT中Header部分的JSON对象实例：

在此 JSON 对象中，type 表示该对象为 JWT,alg 表示创建 JWT 时使用HMAC-SHA256 散列算法计算签名。有效载荷主要用于存储用户信息，如用户 ID，Email，角色和权限信息等。下面是有效载荷的一个简单示例：

而签名则需要使用 Base64URL 编码技术对标头 (Header 和有效载荷(Payload) 进行编码，并作为参数和秘钥一同传递给签名算法，生成最终的签名 (Signature)。以 HMAC-SHA256 算法为例，下面是生成签名的一个伪代码：

现在，我们已经了解了JWT 的基本原理，接下来将使用 Java 来演示生成JWT 的完整过程。关于 Spring Boot 整合 JWT 大家可以参考一个案例学会Spring Security 中使用 JWT!

4、基于 Java 实现的JWT

4-1、依赖

以 Maven 工程为例，需要在 pom.xml 文件中添加入下的配置信息：

如果是非 Maven 工程，你也可以到 Maven 中央仓库搜索 jjwt，然后选择相应的版本(0.9.0)下载到本地，并将 jar 包添加到工程的类路径(classpath)中。

4-2、生成JWT

在工程中新建 JJWTUitls.java 工具类，使用 jjwt 提供的方法实现JWT 的生成，实现细节如下：

在此方法中，JJWT 已经处理好JWT 标头(Header)的信息，我们只需要提供签名所使用的算法(如 SignatureAlgorithm.HS256)，有效载荷，主题(包含了用户信息)，过期时间(exp-time)和秘钥即可，最后使用 jjwt 的 builder()方法组装 JWT。下面是生成秘钥方法 key() 的源代码：

4-3、解析JWT

使用 JJWT 解析JWT 相对简单，首先获取秘钥，然后通过 Jwts.parse() 方法设置秘钥并JWT 进行解析，实现细节如下：

4-4、测试JJWT

最后，在工程中新建一个 JavaJWT.java 类，并在 main 方法中检验 JJWTUtils 工具类中生成和解析JWT 两个方法是否有效。实现细节如下：

如上图所示，“jwt”将作为JWT 标头(Header) “type” 的值，有效载荷(payload)中的主题信息如下：

且JWT 签名的有效时间为60,000毫秒。执行 main 方法，输出信息如下所示：

从测试结果可以看出，我们成功的使用 JJWT 创建并解析了JWT。接下来，我们将了解到在实际的应用中，JWT 对用户信息进行验证的基本流程。关于 Spring Boot 整合 JWT 大家可以参考一个案例学会Spring Security 中使用 JWT!

5、JWT 工作流程

在身份验证中，当用户成功登录系统时，授权服务器将会把 JSON Web Token 返回给客户端，用户需要将此凭证信息存储在本地(cookie或浏览器缓存)。当用户发起新的请求时，需要在请求头中附带此凭证信息，当服务器接收到用户请求时，会先检查请求头中有无凭证，是否过期，是否有效。如果凭证有效，将放行请求；若凭证非法或者过期，服务器将回跳到认证中心，重新对用户身份进行验证，直至用户身份验证成功。以访问 API 资源为例，下图显示了获取并使用JWT 的基本流程：

现在，我们已经完全了解了JWT 是什么，怎么实现以及用来干什么这三个问题。在上述的案例中，我们使用 HS256 算法对JWT 进行签名，在这个过程中，只有身份验证服务器和应用服务器知道秘钥是什么。如果身份验证服务器和应用服务器完全独立，则应用服务器的JWT 校验工作也可以交由认证服务器完成。当客户端对应用服务器发起调用时，应用服务器会使用秘钥对签名进行校验，如果签名有效且未过期，则允许客户端的请求，反之则拒绝请求。关于 Spring Boot 整合 JWT 大家可以参考一个案例学会Spring Security 中使用 JWT!

6、使用JWT 的利弊

优势与劣势是相对而言的，这里主要以传统的 Session 模式作为参考，总结使用JWT 可以获得优势以及带来的弊端。

6-1、使用JWT 的优势

使用 JSON Web Token 保护应用安全，你至少可以获得以下几个优势：

更少的数据库连接：因其基于算法来实现身份认证，在使用JWT 时查询数据的次数更少(更少的数据连接不等于不连接数据库)，可以获得更快的系统响应时间。构建更简单：如果你的应用程序本身是无状态的，那么选择JWT 可以加快系统构建过程。

跨服务调用：你可以构建一个认证中心来处理用户身份认证和发放签名的工作，其他应用服务在后续的用户请求中不需要(理论上)在询问认证中心，可使用自有的公钥对用户签名进行验证。

无状态：你不需要向传统的 Web 应用那样将用户状态保存于 Session 中。

6-2、使用JWT 的弊端

JWT 不是万能的，使用JWT 也会带来诸多问题。就个人使用情况，使用JWT 时可能会面临以下几个麻烦：

严重依赖于秘钥：JWT 的生成与解析过程都需要依赖于秘钥(Secret)，且都以硬编码的方式存在于系统中(也有放在外部配置文件中的)。如果秘钥不小心泄露，系统的安全性将收到威胁。
服务端无法管理客户端的信息：如果用户身份发生异常(信息泄露，或者被攻击)，服务端很难向操作 Session 那样主动将异常用户进行隔离。
服务端无法主动推送消息：服务端由于是无状态的，他将无法使用像 Session 那样的方式推送消息到客户端，例如过期时间将至，服务端无法主动为用户续约，需要客户端向服务端发起续约请求。
冗余的数据开销：一个JWT 签名的大小要远比一个 Session ID 长很多，如果你对有效载荷(payload)中的数据不做有效控制，其长度会成几何倍数增长，且在每一次请求时都需要负担额外的网络开销。
JSON Web Token 很流行，但是它相比于 Session,OIDC(OpenId Connect)等技术还比较新，支持 JSON Web Token 的库还比较少，而且JWT 也并非比传统 Session 更安全，他们都没有解决 CSRF 和 XSS 的问题。因此，在决定使用JWT 前，你需要仔细考虑其利弊。

7、JWT 并非银弹

考虑这样一个问题：如果客户端的JWT 令牌泄露或者被盗取，会发生什么严重的后果？有什么补救措施？

如果单纯的依靠 JSON Web Token 解决用户认证的所有问题，那么系统的安全性将是脆弱的。由于JWT 令牌存储于客户端中，一旦客户端存储的令牌发生泄露事件或者被攻击，攻击者就可以轻而易举的伪造用户身份去修改/删除系统资源，岁如按JWT 自带过期时间，但在过期之前，攻击者可以肆无忌惮的操作系统数据。通过算法来校验用户身份合法性是JWT 的优势，同时也是最大的弊端——它太过于依赖算法。
反观传统的用户认证措施，通常会包含多种组合，如手机验证码，人脸识别，语音识别，指纹锁等。用户名和密码只做用户身份识别使用，当用户名和密码泄露后，在遇到敏感操作时(如新增，修改，删除，下载，上传)，都会采用另外的方式对用户的合法性进行验证(发送验证码，邮箱验证码，指纹信息等)以确保数据安全。
与传统的身份验证方式相比，JWT 过多的依赖于算法，缺乏灵活性，而且服务端往往是被动执行用户身份验证操作，无法及时对异常用户进行隔离。那是否有补救措施呢？答案是肯定的。接下来，将介绍在发生令牌泄露事件后，如何保证系统的安全。

关于 Spring Boot 整合 JWT 大家可以参考一个案例学会Spring Security 中使用 JWT!

8、JWT 爬坑指南

不管是基于 Sessions 还是基于 JSON Web Token，一旦密令被盗取，都是一件棘手的事情。接下来，将讲述基于 JSON Web Token 的方式发生令牌泄露是该采取什么样的措施(解决方案包含但不局限与本文所涉及的内容)。

为了防止用户JWT 令牌泄露而威胁系统安全，你可以在以下几个方面完善系统功能：

清除已泄露的令牌：此方案最直接，也容易实现，你需将JWT 令牌在服务端也存储一份，若发现有异常的令牌存在，则从服务端令牌列表中将此异常令牌清除。当用户发起请求时，强制用户重新进行身份验证，直至验证成功。对于服务端的令牌存储，可以借助 Redis 等缓存服务器进行管理，也可以使用 Ehcache 将令牌信息存储在内存中。
敏感操作保护：在涉及到诸如新增，修改，删除，上传，下载等敏感性操作时，定期(30分钟，15分钟甚至更短)检查用户身份，如手机验证码，扫描二维码等手段，确认操作者是用户本人。如果身份验证不通过，则终止请求，并要求重新验证用户身份信息。
地域检查：通常用户会在一个相对固定的地理范围内访问应用程序，可以将地理位置信息作为一个辅助来甄别用户的JWT 令牌是否存在问题。如果发现用户A由经常所在的地区 1 变到了相对较远的地区 2 ，或者频繁在多个地区间切换，不管用户有没有可能在短时间内在多个地域活动(一般不可能)，都应当终止当前请求，强制用户重新进行验证身份，颁发新的JWT 令牌，并提醒(或要求)用户重置密码。
监控请求频率：如果JWT 密令被盗取，攻击者或通过某些工具伪造用户身份，高频次的对系统发送请求，以套取用户数据。针对这种情况，可以监控用户在单位时间内的请求次数，当单位时间内的请求次数超出预定阈值值，则判定该用户密令是有问题的。例如 1 秒内连续超过 5 次请求，则视为用户身份非法，服务端终止请求并强制将该用户的JWT 密令清除，然后回跳到认证中心对用户身份进行验证。
客户端环境检查：对于一些移动端应用来说，可以将用户信息与设备(手机,平板)的机器码进行绑定，并存储于服务端中，当客户端发起请求时，可以先校验客户端的机器码与服务端的是否匹配，如果不匹配，则视为非法请求，并终止用户的后续请求。