JSON Web Token 简介
JSON Web Token（缩写 JWT）是目前最流行的跨域认证解决方案，本文介绍它的原理和用法。
什么是JSON Web Token？
JSON Web Token（JWT）是一个开放标准（RFC 7519），它定义了一种紧凑且独立的方式，用于在各方之间作为JSON对象安全地传输信息。此信息可以通过数字签名进行验证和信任。JWT可以使用秘密（使用HMAC算法）或使用RSA或ECDSA的公钥/私钥对进行签名。
虽然JWT可以加密以在各方之间提供保密，但我们将专注于签名令牌。签名令牌可以验证其中包含的声明的完整性，而加密令牌则隐藏其他方的声明。当使用公钥/私钥对签名令牌时，签名还证明只有持有私钥的一方是签署它的一方。
什么时候应该使用JSON Web Token？
以下是JSON Web令牌有用的一些场景：
- 授权：
这是使用JWT的最常见方案。一旦用户登录，每个后续请求将包括JWT，允许用户访问该令牌允许的路由，服务和资源。Single Sign On是一种现在广泛使用JWT的功能，因为它的开销很小，并且能够在不同的域中轻松使用。
- 信息交换：
JSON Web令牌是在各方之间安全传输信息的好方法。因为JWT可以签名 - 例如，使用公钥/私钥对 - 您可以确定发件人是他们所说的人。此外，由于使用标头和有效负载计算签名，您还可以验证内容是否未被篡改。
什么是JSON Web Token结构？
在紧凑的形式中，JSON Web Tokens由dot（.）分隔的三个部分组成，它们是：
- Header 头
- Payload 有效载荷
- Signature 签名
因此，JWT通常如下所示。
xxxxx.yyyyy.zzzzz
让我们分解不同的部分。
头
标头通常由两部分组成：令牌的类型，即JWT，以及正在使用的签名算法，例如HMAC SHA256或RSA。
例如：
{
"alg": "HS256",
"typ": "JWT"
}
然后，这个JSON被编码为Base64Url，形成JWT的第一部分。
有效载荷
令牌的第二部分是有效负载，其中包含声明。声明是关于实体（通常是用户）和其他数据的声明。索赔有三种类型：注册，公开和私人索赔。
- 已注册的声明：
这些是一组预定义声明，不是强制性的，但建议使用，以提供一组有用的，可互操作的声明。其中一些是： iss（发行人）， exp（到期时间），子（主题）， aud（观众）等。请注意，声明名称只有三个字符，因为JWT意味着紧凑。
- 公开声明：
这些可以由使用JWT的人随意定义。但为避免冲突，应在 IANA JSON Web令牌注册表中定义它们，或者将其定义为包含防冲突命名空间的URI。
- 私人索赔：
这是创建共享使用它们同意并既不是当事人之间的信息自定义声明注册或公众的权利要求。
示例有效负载可以是：
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
补充：
iss (issuer)：签发人
exp (expiration time)：过期时间
sub (subject)：主题
aud (audience)：受众
nbf (Not Before)：生效时间
iat (Issued At)：签发时间
jti (JWT ID)：编号
然后，有效负载经过Base64Url编码，形成JSON Web令牌的第二部分。请注意，对于签名令牌，此信息虽然可以防止被篡改，但任何人都可以读取。除非加密，否则不要将秘密信息放在JWT的有效负载或头元素中。
签名
要创建签名部分，您必须采用编码标头，编码的有效负载，秘密，标头中指定的算法，并对其进行签名。
例如，如果要使用HMAC SHA256算法，将按以下方式创建签名：
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
签名用于验证消息在此过程中未被更改，并且，在使用私钥签名的令牌的情况下，它还可以验证JWT的发件人是否是它所声称的人。
全部放在一起
输出是三个由点分隔的Base64-URL字符串，可以在HTML和HTTP环境中轻松传递，而与基于XML的标准（如SAML）相比更加紧凑。
下面显示了一个JWT，它具有先前的头和有效负载编码，并使用机密签名。
如果您想使用JWT并将这些概念付诸实践，您可以使用jwt.io Debugger来解码，验证和生成JWT。
JSON Web令牌如何工作？
在身份验证中，当用户使用其凭据成功登录时，将返回JSON Web令牌。由于令牌是凭证，因此必须非常小心以防止出现安全问题。一般情况下，您不应该将令牌保留的时间超过要求。
每当用户想要访问受保护的路由或资源时，用户代理应该使用承载模式发送JWT，通常在Authorization标头中。标题的内容应如下所示：
Authorization: Bearer <token>
在某些情况下，这可以是无状态授权机制。服务器的受保护路由将检查Authorization标头中的有效JWT ，如果存在，则允许用户访问受保护资源。如果JWT包含必要的数据，则可以减少查询数据库以进行某些操作的需要，尽管可能并非总是如此。
如果在标Authorization头中发送令牌，则跨域资源共享（CORS）将不会成为问题，因为它不使用cookie。
下图显示了如何获取JWT并用于访问API或资源：
- 1.应用程序或客户端向授权服务器请求授权。这是通过其中一个不同的授权流程执行的。例如，典型的OpenID Connect兼容Web应用程序将/oauth/authorize使用授权代码流通过端点。
- 2.授予授权后，授权服务器会向应用程序返回访问令牌。
- 3.应用程序使用访问令牌来访问受保护资源（如API）。
请注意，使用签名令牌，令牌中包含的所有信息都会向用户或其他方公开，即使他们无法更改。这意味着您不应该在令牌中放置秘密信息。
我们为什么要使用JSON Web令牌？
让我们来谈谈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令牌的便利性。
以上来自官网简介翻译，如有翻译错误的地方请参考官方简介：https://jwt.io/introduction
补充一、跨域认证的问题
互联网服务离不开用户认证。一般流程是下面这样。
- 1、用户向服务器发送用户名和密码。
- 2、服务器验证通过后，在当前对话（session）里面保存相关数据，比如用户角色、登录时间等等。
- 3、服务器向用户返回一个 session_id，写入用户的 Cookie。
- 4、用户随后的每一次请求，都会通过 Cookie，将 session_id 传回服务器。
- 5、服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。
这种模式的问题在于，扩展性（scaling）不好。单机当然没有问题，如果是服务器集群，或者是跨域的服务导向架构，就要求 session 数据共享，每台服务器都能够读取 session。
举例来说，A 网站和 B 网站是同一家公司的关联服务。现在要求，用户只要在其中一个网站登录，再访问另一个网站就会自动登录，请问怎么实现？
一种解决方案是 session 数据持久化，写入数据库或别的持久层。各种服务收到请求后，都向持久层请求数据。这种方案的优点是架构清晰，缺点是工程量比较大。另外，持久层万一挂了，就会单点失败。
另一种方案是服务器索性不保存 session 数据了，所有数据都保存在客户端，每次请求都发回服务器。JWT 就是这种方案的一个代表。
补充二、JWT的原理
JWT 的原理是，服务器认证以后，生成一个 JSON 对象，发回给用户，就像下面这样。
{
"username": "zhangsan",
"role": "admin",
"expirationTime": "2019-8-13 13:50:14"
}
以后，用户与服务端通信的时候，都要发回这个 JSON 对象。服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名。
服务器就不保存任何 session 数据了，也就是说，服务器变成无状态了，从而比较容易实现扩展。
补充三、JWT的特点
- 1、JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
- 2、JWT 不加密的情况下，不能将秘密数据写入 JWT。
- 3、JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。
- 4、JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。
- 5、JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
- 6、为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。
参考文档：
http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html