JWT token 介绍
JWT token 介绍
JSON Web Token (JWT) 是一个开放标准 (RFC 7519)，它定义了一种紧凑（compact）且自包含（self-contained）的方式，用于在各方之间以JSON 对象方式安全地传输信息。
此信息是数字签名的，可以验证和信任。JWT 可以使用密钥（使用 HMAC 算法）或使用 RSA 或 ECDSA 的公钥/私钥对进行签名。
虽然 JWT 可以加密以在各方之间提供保密性，但我们将专注于签名令牌。签名的令牌可以验证其中包含的声明的完整性，而加密的令牌会向其他方隐藏这些声明。当使用公钥/私钥对对令牌进行签名时，只有持有私钥的一方才可以签署。
什么时候使用 JWT token
一些使用场景：
授权（Authorization）：这是最常见的场景。用户登录后，每个后续请求都将包含 JWT，从而允许用户访问该令牌允许的路由、服务和资源。 单点登录是当今广泛使用 JWT 的一项功能，因为它的开销很小并且能够在不同的域中轻松使用。
信息交换（Information Exchange）：JWT令牌是在各方之间安全传输信息的好方法。 因为可以对 JWT 进行签名（例如，使用公钥/私钥对），所以可以确定发件人就是他们所说的那个人。此外，由于使用 header和payload 计算签名，还可以验证内容是否被篡改。
JWT 结构
JWT 由三部分组成，以 . 分割：
- Header
- Payload
- Signature
JWT 最终看起来是这样子：
xxxxx.yyyyy.zzzzz
Header
header 通常由两部分组成：令牌的类型，即 JWT，以及正在使用的签名算法，例如 HMAC SHA256 或 RSA。
{
"alg": "HS256",
"typ": "JWT"
}
然后，这个 JSON 被 Base64Url 编码以形成 JWT 的第一部分。
Payload
令牌的第二部分是有效负载，其中包含声明。 声明是关于实体（通常是用户）和附加数据的陈述。 声明分为三种类型：registered, public, private claims.
注册（registered）声明：这是一组预定义的声明，不是强制性的，但建议使用。以提供一组有用的、可互操作的声明。比如：iss（发行人）、exp（到期时间）、sub（主题）、aud（受众）等。
公共（public）声明：这些可以由使用人随意定义。 但是为了避免冲突，应该在 IANA JSON Web Token Registry 中定义，或者定义为包含抗冲突命名空间的 URI。
私有（private）声明：这些是为在同意使用它们的各方之间共享信息而创建的自定义声明，既不是注册声明也不是公共声明。
eg.
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
然后对有效负载进行 Base64Url 编码以形成 JSON Web 令牌的第二部分。
注意，对于已签名的令牌，此信息虽然受到保护以防篡改，但任何人都可以读取。除非已加密，否则请勿将机密信息放入 JWT 的有效负载或标头元素中。
Signature
要创建签名部分，必须获取已编码的标头（header）、编码的有效负载（payload）、密钥、header中指定的算法，并对其进行签名。
例如，如果您想使用 HMAC SHA256 算法，签名将通过以下方式创建：
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
签名用于验证信息在传输过程中是否被篡改，并且在使用私钥签名令牌的情况下，它还可以验证 JWT 的发送者是否正确。
完整JWT
由三个 . 分隔的 Base64-URL 字符串，可以在 HTML 和 HTTP 环境中轻松传递，相对于基于 XML 的标准（如 SAML）则更紧凑。
下面显示了一个 JWT，该 JWT 具有先前的标头和有效负载编码，并使用秘密签名：
我们可以在 jwt.io Debugger 网站来解码、验证和生成 JWT。
JWT 使用方式
在身份校验中，当用户成功登录，将返回一个 JSON Web Token。由于令牌是凭据，因此必须非常小心以防止出现安全问题。
通常，不应将令牌保留超过所需的时间。
由于缺乏安全性，也不应该将敏感的会话数据存储在浏览器存储中。
每当用户想要访问受保护的路由或资源时，用户代理应该发送 JWT，通常在 Authorization header 中使用 Bearer 模式。 header 的内容应如下所示：
Authorization: Bearer <token>
某些情况下，这可以是一种无状态授权机制。服务器的受保护路由将检查 Authorization header 中是否存在有效的 JWT，如果存在，则允许用户访问受保护的资源。如果 JWT 包含必要的数据，则可能会减少查询数据库以进行某些操作的需要，尽管情况并非总是如此。
如果 token 在 Authorization header，跨域 Cross-Origin Resource Sharing (CORS)不是问题，因为它不使用 cookies。
获取 JWT 并将其用于访问 API 或资源，示意图：
- 应用程序或客户端向授权服务器请求授权。这是通过不同的授权流程之一执行的。例如，一个典型的符合 OpenID Connect 的 Web 应用程序将使用授权代码流请求 /oauth/authorize 端点。
- 当授权被授予时，授权服务器向应用程序返回一个访问令牌。
- 应用程序使用访问令牌访问受保护的资源（如 API）。
注意：
使用签名令牌，令牌中包含的所有信息都会向外公开，虽然他们无法更改，也不应将敏感信息放入令牌中。
为什么使用 JWT
相对于 Simple Web Tokens (SWT) 和 Security Assertion Markup Language Tokens (SAML)
，我们来看看JSON Web Tokens (JWT)的优势。
由于JSON不像XML那样冗长，因此在对其进行编码时，它的大小也更小，这使得 JWT 比 SAML 更紧凑。这使得 JWT 成为在 HTML 和 HTTP 环境中传递信息的一个不错选择。
安全方面，SWT 只能通过使用 HMAC 算法的共享密钥进行对称签名。但是，JWT 和 SAML 令牌可以使用 X.509 证书形式的公钥/私钥对进行签名。 与签署 JSON 的简单性相比，使用 XML 数字签名签署 XML 而不引入隐蔽的安全漏洞是非常困难的。
JSON 解析器在大多数编程语言中都很常见，因为它们直接映射到对象。相反，XML 没有自然的文档到对象映射。这使得使用 JWT 比使用 SAML 断言更容易。
JSON Web 令牌在多个平台，尤其是移动平台，具有无比的便利性。
存在问题
token 保存问题：
用户每次登录，后端生成一个jwt token，返回给调用者，并将token保存到数据库与用户绑定。一个用户绑定一个 token?每次登陆刷新token 还是一个用户绑定 n个token
token 时效问题:
token 失效时间设置多长？
设置太长，比如一年以上，好像意义不大，设置时间太短，频繁失败提醒也很烦。
参考：
2022.01.21 晨间
上海 虹桥
