JSON Web Token 简介

JWT 快速入门

JSON Web Token 简称 JWT

JWT是一种开放的行业标准(RFC 7519)方法，用于在双方之间安全地表示声明，也是目前较流行的跨域身份验证解决方案之一。JWT定义了一种宽松且紧凑的数据组合方式，使用 JSON 对象在各应用之间传输加密信息。该 JSON 对象可以通过数字签名进行鉴签和校验，一般地，JWT 可以采用 HMAC 算法，RSA 或者 ECDSA 的公钥/私钥对数据进行签名操作。

JWT呈现形式是一个字符串，这个字符串由三个部份组成：头部(header)、载荷(payload)与签名(signature)，三个部分用.拼接：如下：

header.payload.signature

头部：header

头部用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的算法等。这也可以被表示成一个JSON对象。

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

在头部指明了签名算法是HS256算法。我们进行BASE64编码：

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

载荷：playload

载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品，这些有效信息包含三个部分

1）标准中注册的声明（建议但不强制使用）

iss: jwt签发者
sub: jwt所面向的用户
aud: 接收jwt的一方
exp: jwt的过期时间，这个过期时间必须要大于签发时间
nbf: 定义在什么时间之前，该jwt都是不可用的.
iat: jwt的签发时间
jti: jwt的唯一身份标识，主要用来作为一次性token。

2）公共的声明

公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密.

3）私有的声明

私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。

这个指的就是自定义的claim。比如前面那个结构举例中的admin和name都属于自定的claim。这些claim跟JWT标准规定的claim区别在于：JWT规定的claim，JWT的接收方在拿到JWT之后，都知道怎么对这些标准的claim进行验证(还不知道是否能够验证)；而private claims不会验证，除非明确告诉接收方要对这些claim进行验证以及规则才行。

定义一个payload:

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

然后将其进行base64加密，得到Jwt的第二部分。

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

签证（signature）

jwt的第三部分是一个签证信息，这个签证信息由三部分组成：

header (base64后的)

payload (base64后的)

secret

这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

注意：

secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。
如果需要在url中传输jwt，则需要使用base64url计算header, payload, 以及 signature的值。
因为jwt使用是base64算法是公开可逆的，所以其实任何人，只要拿到了你的jwt字符串都可以将jwt各部数的数据decode后查看到原数据；因此，不要在原数据中放敏感信息，如密码，邮箱，手机号之类的。
考虑到以上第3点问题，与服务端的连接最好使用https，以https的方式向服务端传递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 前，你需要仔细考虑其利弊。

如果客户端的 JWT 令牌泄露或者被盗取，会发生什么严重的后果？

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

为了防止用户 JWT 令牌泄露而威胁系统安全，有什么补救措施？

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