什么是 JWT？

JSON Web Token (JWT) 是一个开放标准 ( RFC 7519 )，它定义了一种紧凑且自包含的方式，用于在各方之间作为 JSON 对象安全地传输信息。

传统的Session验证

1.用户名密码登陆。

2.验证通过，server存储登陆状态，并返回session ID给cliet。

3.后续请求带着session ID，服务器根据已存储的session进行校验。

4.返回请求结果。

(服务端要存储登陆状态，这对单机模式没什么用影响，对于集群模式是很大的挑战，为了方便横向扩展，要把这些登陆态拆出来，常见的做法是写入redis集群和持久化session数据，有了redis程序员就可以大展身手了，可以把很多信息放入redis，不在局限于session ID，经常把用户信息也放入进去，这就会照成很多未知风险，虽然技术规范可以规避一些风险，但是单点风险还是存在的。)

 JSON Web Tokens 应用场景

• 授权：这是使用 JWT 最常见的场景。用户登录后，每个后续请求都将包含 JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是当今广泛使用 JWT 的一项功能，因为它的开销很小，并且能够轻松跨不同域使用。

• 信息交换：JSON Web Tokens 是一种在各方之间安全传输信息的好方法。因为 JWT 可以被签名。例如，使用公钥/私钥对，你可以确定发件人就是你确定的人。此外，由于使用标头和有效负载计算签名，因此您还可以验证内容是否未被篡改。

下面显示了一个 JWT。  

其中 JSON Web Tokens 由点 ( .)分隔的三个部分组成，它们是：

• Header（头部）
• Payload（载荷）
• Signature（签名）

Header

header通常由2个部分组成：token的类型（JWT）; token所采用的签名算法（例如HMAC SHA256或者RSA）。例如：

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

最后，使用Base64 URL算法将上述JSON对象转换为字符串保存。

Payload

令牌的第二部分是负载，其中包含声明（关于实体（通常是用户）和附加数据的声明）。

共有三种类型的声明：注册声明，公开声明，私有声明。

• 注册声明
  ：这些是一组预定义的声明，这些声明不是强制性的，而是推荐的，以提供一组有用的、可互操作的声明。其中一些是： iss（发行者）、 exp（到期时间）、 sub（主题）、 aud（受众）等。请注意，声明名称只有三个字符，因为 JWT 是紧凑的。

• 公共声明
  ：这些可以由使用 JWT 的人随意定义。但是为了避免冲突，它们应该在IANA JSON Web Token Registry
  中定义或定义为包含抗冲突命名空间的 URI。

• 私人声明
  ：这些都是使用它们同意并既不是当事人之间建立共享信息的自定义声明注册或公众的权利要求。

一个示例有效载荷可能是：

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

然后对有效负载进行Base64Url编码以形成 JSON Web 令牌的第二部分。

（请注意，对于已签名的令牌，此信息虽然受到防篡改保护，但任何人都可以读取。除非加密，否则不要将机密信息放在 JWT 的负载或标头元素中。）

Signature

对上面两部分数据签名，通过指定的算法生成哈希，以确保数据不会被篡改。

签名用于验证消息在此过程中没有更改，并且在使用私钥签名的令牌的情况下，它还可以验证 JWT 的发送者是它所说的那个人。

首先，需要指定一个密码（secret）。该密码仅仅为保存在服务器中，并且不能向用户公开。然后，使用标头中指定的签名算法（默认情况下为HMAC SHA256）根据以下公式生成签名。

 例如，如果要使用 HMAC SHA256 算法，则签名将通过以下方式创建：

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

注：默认情况下JWT是未加密的，任何人都可以解读其内容，因此不要构建隐私信息字段，存放保密信息，以防止信息泄露。

JSON 网络令牌如何工作？

在身份验证中，当用户使用其凭据成功登录时，将返回 JSON Web Token。由于令牌是凭证，因此必须非常小心以防止出现安全问题。通常，您不应将令牌保留的时间超过所需的时间。

由于缺乏安全性，您也不应该在浏览器存储中存储敏感的会话数据。

每当用户想要访问受保护的路由或资源时，用户代理应该发送 JWT，通常在使用Bearer模式的Authorization标头中。标题的内容应如下所示：

Authorization: Bearer <token>

在某些情况下，这可以是无状态授权机制。服务器的受保护路由将检查Authorization标头中的有效 JWT ，如果存在，则用户将被允许访问受保护的资源。如果 JWT 包含必要的数据，则可能会减少为某些操作查询数据库的需要，尽管情况并非总是如此。

如果令牌在Authorization标头中发送，跨源资源共享 (CORS) 不会成为问题，因为它不使用 cookie。

下图显示了如何获取 JWT 并将其用于访问 API 或资源：

1. 应用程序或客户端向授权服务器请求授权。这是通过不同的授权流程之一执行的。例如，典型的OpenID Connect兼容 Web 应用程序将/oauth/authorize使用授权代码流通过端点。
2. 当授权被授予时，授权服务器向应用程序返回一个访问令牌。
3. 应用程序使用访问令牌来访问受保护的资源（如 API）。

请注意，使用签名令牌，令牌中包含的所有信息都会暴露给用户或其他方，即使他们无法更改它。这意味着您不应将秘密信息放入令牌中。

我们为什么要使用 JSON Web Tokens？

让我们来谈谈JSON Web Tokens (JWT)与Simple Web Tokens (SWT)和Security Assertion Markup Language Tokens (SAML) 相比的优势。

由于 JSON 没有 XML 冗长，因此在编码时它的大小也更小，这使得 JWT 比 SAML 更紧凑。这使得 JWT 成为在 HTML 和 HTTP 环境中传递的不错选择。

在安全方面，SWT 只能由使用 HMAC 算法的共享秘密对称签名。但是，JWT 和 SAML 令牌可以使用 X.509 证书形式的公钥/私钥对进行签名。与签署 JSON 的简单性相比，在不引入模糊安全漏洞的情况下使用 XML 数字签名签署 XML 是非常困难的。

JSON 解析器在大多数编程语言中都很常见，因为它们直接映射到对象。相反，XML 没有自然的文档到对象映射。这使得使用 JWT 比使用 SAML 断言更容易。

关于使用，JWT 用于互联网规模。这突出了客户端在多个平台（尤其是移动平台）上处理 JSON Web 令牌的简便性