认证姿势-Jwt-基础篇
一、定义
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.
Json Web Token简称Jwt，是一种开放标准 (RFC 7519)，它定义了一种紧凑且自包含的方式，用于在各方之间数据作为JSON对象安全地传输信息。数据信息经过数字签名，可以被验证和信任。JWT可以使用秘密（使用 HMAC算法）或使用RSA或 ECDSA的公钥/私钥对进行签名。Jwt中签名加密解密主要依靠加密令牌和签名令牌，加密令牌将信息进行加密，避免其他方知道对应声明的信息内容，签名令牌验证加密信息中声明的完整性，当使用公钥/私钥对对令牌进行签名时，签名还证明只有持有私钥的一方才是对其进行签名的一方 。
二、结构
一个jwt包含以下结构：
Header
Payload
Signature
各个部分以点.进行分隔，xxxx.yyyy.zzzz。
1、Header
头部由令牌类型Jwt以及签名使用的加密算法类型组成，例如HMAC SHA256 或 RSA。该部分由Base64Url方式进行编码。
{
"alg": "HS256",
"typ": "JWT"
}2、Payload
负载部分，包含了声明部分，声明是对用户实体信息以及附加数据信息的声明，分为三种类型，registered声明、public声明和private声明。
registered声明，为一组系列规则预定义的可用的，可互操作的声明，例如iss(发行者)、exp(到期时间)、sub(主题)、aud(受众)等。声明名称仅仅三个字符，在自定义时需要注意该细节。该部分同样由Base64Url进行编码。
public声明，为使用JWT的人随意定义，为避免冲突，用户自定义时，应尽量避开[官方规范]https://www.iana.org/assignments/jwt/jwt.xhtml中包含的声明。
private声明，由同意使用它们的各方之间共享信息而创建的自定义信息。
案例如下：
{
"sub":"testsub",
"name":"ggcy",
"iat":1516239022
}需要注意的是，在 Header 和 Payload 中避免存放涉及到私密内容，整体信息防篡改，但是对信息并不负责，数据内容的安全性，这里是读者需要注意的地方。
3、Signature
创建指纹，需要以下几个部分，Header、Payload、一个秘钥，其中 Header 和 Payload 都是需要 Base64Url 进行编码，几个部分最终由 Header 定义的加密算法进行加密。具体抽象逻辑如下：
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)案例如下：header
{
"alg": "HS256",
"typ": "JWT"
}
payload
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}
signature
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
your-256-bit-secret
)
//生成结果如下
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
组合Jwt，结构如下：xxx.yyy.zzz，内容每一部分由.，进行间隔。
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c如果觉得以上内容过于枯燥，想要更具体的体会对应的各个部分的内容，可以访问Jwt官方提供的在线Jwt生成页面，https://jwt.io/#debugger-io，进行尝试测试。
三、工作流程
1、用户请求特定的授权链接进行认证授权，获取对应用户凭证。
2、用户凭证登录成功后，用户能够获取到一个带有 Jwt 的返回结果，获取到的 Jwt 仅仅是在有效时间内能够正常使用，操作有效时间，就将失效。
3、当用户要访问对应受到权限保护的 Api 和资源时，都需要头部带有对应有效的 Jwt ，通常在 Header 中，参数作为 Authorization ，参数内置格式为 Beaer {token} 的方式，附带到当前的请求中。
四、好处和不足
说了工作原理，那对应使用 Jwt 有什么好处？或者说有什么优缺点？
首先考虑一个问题，传统的凭证下发方式都有哪些？
简单网络令牌 (SWT) 和安全断言标记语言令牌 (SAML)
1、好处
1）结构上
相比Xml，Json的结构更加紧凑，字符串进行编码时，占用的空间更少。
2）安全上
SWT 只能由使用 HMAC 算法的共享秘密对称签名，JWT 和 SAML 令牌可以使用 X.509 证书形式的公钥/私钥对进行签名，使用 Xml 在避免引入隐藏的安全相对于 Json 是更困难的。
3）使用上
Json 解释器对于大多数编程语言来说，更加方便，能够将结构直接映射到对象上，操作上更加便捷。Jwt中携带的公开信息，也能为跨系统交互提供一定的辅助操作。
2、不足
1）不是银弹
Jwt 并没有解决传统 Session 、 Cookie 、OIDC(OpenId Connect) 等方式的跨域和 XSS 问题。
2）依赖秘钥加密解密
Jwt的生成和解密都需要依赖于 Secret ，常常需要以硬编码方式嵌入到系统中（或配置文件），对于秘钥的管控，影响了系统的安全性指数。
3）客户端控制缺失
一旦生成 Jwt 下发到客户端，保存在 Jwt 中的信息将对使用者来说，有效期间内，可视为透明，如果想要像 Session 那样进行远程控制异常账户，就需要使用更多的手段去弥补。
4）冗余的数据开销
本质上，对于 Session 来说，Jwt的数据长度是比前者大的，如果不对Payload的长度进行限制，实际长度和内容大小的优势将不复存在。
五、总结
从以上对 Jwt 的学习过程中，可以了解到，Jwt 只是一种在用户认证授权过程中，采取的一种比较简单并且防信息篡改的凭证方式，并不是事事都能估计和全面的银弹，使用时应当依据实际情况进行选择。
六、参考链接
[1]JWT-JSON WEB TOKEN使用详解及注意事项：https://cloud.tencent.com/developer/article/1542175 [2] Jwt 介绍https://jwt.io/introduction
往期推荐