JWT 翻译
jwt官网：
JSON Web Token Introduction - jwt.io
https://jwt.io/introduction标准 RFC 7519 ：
https://datatracker.ietf.org/doc/html/rfc7519#section-4.1https://datatracker.ietf.org/doc/html/rfc7519#section-4.1
JWT
定义
JWT 全称 JSON Web Token，是一个开放标准（RFC 7519），它定义了一种紧凑且自包含的方式，用于作为JSON对象在各方之间安全地传输信息。
该信息可以被验证和信任，因为它是数字签名的。
可以使用秘密（使用HMAC算法）或使用RSA或ECDSA的公钥/私钥对对jwt进行签名。
虽然jwt也可以加密以在各方之间提供保密性，但我们将重点关注已签名的令牌。
签名令牌可以验证其中包含的声明的完整性，而加密令牌则对其他方隐藏这些声明。
当使用公钥/私钥对对令牌进行签名时，签名还证明只有持有私钥的一方是对其进行签名的一方。
使用
Authorization
这是使用JWT最常见的场景。
用户登录后，每个后续请求都将包含JWT，允许用户访问该令牌允许的路由、服务和资源。
单点登录是目前广泛使用JWT的一个特性，因为它的开销很小，并且能够轻松地跨不同的域使用。
Information Exchange
JSON Web令牌是各方之间安全传输信息的好方法。
因为可以对jwt进行签名（例如，使用公钥/私钥对），所以可以确保发送者就是他们所说的那个人。
此外，由于签名是使用报头和有效负载计算的，因此您还可以验证内容是否未被篡改。
JWT结构
数据结构 ： header.payload.signature
header
header通常由两部分组成：令牌的类型（JWT）和使用的签名算法（如HMAC SHA256或RSA）。
{
"alg": "HS256",
"typ": "JWT"
}然后，对该JSON进行Base64Url编码，以形成JWT的第一部分。
payload
令牌的第二部分是有效负载，它包含声明。
声明是关于实体（通常是用户）和附加数据的陈述。
claims类型
registered, public和private claims
registered
这些是一组预定义的声明，它们不是强制性的，但推荐使用，以提供一组有用的、可互操作的声明。
其中包括：iss（发行者）、exp（过期时间）、sub（主题）、aud（受众）等。
public
这些可以由使用jwt的人随意定义。
但是为了避免冲突，它们应该在IANA JSON Web令牌注册表中定义，或者定义为包含抗冲突名称空间的URI。
private
这些是为了在同意使用它们的各方之间共享信息而创建的自定义声明，它们既不是注册声明，也不是公共声明。
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}然后对有效负载进行Base64Url编码，以形成JSON Web令牌的第二部分。
signature
要创建签名部分，您必须使用已编码的报头、已编码的有效载荷、一个秘密、报头中指定的算法，并对其进行签名。
例如，如果您想使用HMAC的SHA256算法，签名将按以下方式创建：
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)签名用于验证消息在发送过程中没有被更改，并且，对于使用私钥签名的令牌，它还可以验证JWT的发送者是否就是它所说的那个人。
拼接数据
输出是三个用点分隔的Base64-URL字符串，可以很容易地在HTML和HTTP环境中传递，同时与基于xml的标准（如SAML）相比更加紧凑。
在线运行：JSON Web Tokens - jwt.ioJSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed using JSON Web Signature (JWS).https://jwt.io/
JWT工作原理
在身份验证中，当用户使用其凭据成功登录时，将返回一个JSON Web Token。
由于令牌是凭证，因此必须非常小心地防止安全问题。
一般来说，不应该保留令牌超过所需的时间。
每当用户想要访问受保护的路由或资源时，用户代理应该发送JWT，通常在Authorization头中使用承载模式。
头文件的内容应该如下所示：
Authorization: Bearer 在某些情况下，这可以是一种无状态授权机制。服务器受保护的路由将检查Authorization报头中的有效JWT，如果存在，则允许用户访问受保护的资源。如果JWT包含必要的数据，那么为某些操作查询数据库的需求可能会减少，尽管情况并非总是如此。
注意，如果通过HTTP头发送JWT令牌，则应该尽量防止它们变得太大。有些服务器不接受超过8 KB的报头。如果您试图在JWT令牌中嵌入太多信息，比如包含所有用户的权限，那么您可能需要一个替代解决方案，比如Auth0 Fine-Grained Authorization：
Fine-Grained Authorization (FGA) at scale for developers - Auth0Implement Fine-Grained Authorization (FGA) quickly to let users work securely while controlling access using developer friendly API’s in an existing system.https://auth0.com/fine-grained-authorization如果令牌是在授权头中发送的，那么跨域资源共享（Cross-Origin Resource Sharing， CORS）就不会出现问题，因为它不使用cookie。
下图显示了如何获得JWT并使用JWT访问api或资源：
步骤1
应用程序或客户端向授权服务器请求授权。
这是通过一个不同的授权流执行的。
例如，一个典型的OpenID Connect兼容的web应用程序将使用授权代码流通过/oauth/ authorization端点。
步骤2
授予授权后，授权服务器将向应用程序返回一个访问令牌。
步骤3
应用程序使用访问令牌访问受保护的资源（如API）。
请注意，使用已签名的令牌，令牌中包含的所有信息都将公开给用户或其他方，即使他们无法更改它。这意味着您不应该在令牌中放入机密信息。
验证和验证JWT之间的区别
JSON Web令牌（JWT）的验证和验证对安全性至关重要，但它们处理的JWT安全性方面略有不同：验证确保令牌格式良好，并包含可执行的声明；验证确保令牌是真实且未被修改的。
让我们更详细地探讨验证和验证的区别：
JWT验证一般是指检查JWT的结构、格式和内容：
结构：确保令牌有标准的三部分（标头、有效载荷、签名），用点分隔。
格式：验证每个部分的编码是否正确（Base64URL），以及有效负载是否包含预期的声明。
内容：检查有效负载内的声明是否正确，例如过期时间（exp）、在（iat）而不是在（nbf）之前发布，以及其他，以确保令牌未过期、未在到期之前使用等。
另一方面，JWT验证涉及确认令牌的真实性和完整性：
签名验证：
这是验证的主要方面，根据报头和有效负载检查JWT的签名部分。
这是使用头中指定的算法（如HMAC、RSA或ECDSA）和密钥或公钥来完成的。
如果签名与期望的不匹配，则令牌可能已被篡改或来自不受信任的来源。
发行者验证：检查iss声明是否与预期的发行者匹配。
受众检查：确保claims符合预期的受众。
在实践中：
您验证JWT以确保令牌是有意义的，符合预期的标准，包含正确的数据。
您可以验证JWT，以确保令牌没有被恶意更改，并且来自可信的来源。
在许多系统中，这些步骤通常被合并到俗称的“JWT验证”中，它包含了全面安全检查的验证和验证。
尽管如此，他们的区别仍然存在。
JWT解码和编码的区别
编码JWT
涉及到将报头和有效负载转换为紧凑的url安全格式。
header（说明签名算法和令牌类型）和payload（包括主题、过期和发布时间等声明）都被转换为JSON，然后对Base64URL进行编码。
然后将这些编码的部分与一个点连接起来，然后使用头中指定的带有密钥或私钥的算法生成签名。
此签名也是Base64URL编码的，从而产生最终的JWT字符串，该字符串以适合传输或存储的格式表示令牌。
解码JWT
通过将Base64URL编码的header和payload转换回JSON来逆转这个过程，允许任何人在不需要密钥的情况下读取这些部分。
然而，在这种情况下，“解码”通常扩展到包括对令牌签名的验证。此
验证步骤包括使用最初使用的相同算法和密钥重新签名已解码的报头和有效负载，然后将此新签名与JWT中包含的签名进行比较。
如果它们匹配，则确认令牌的完整性和真实性，确保自发行以来未被篡改。