随着前后端分离越来越普及，传统的基于cookie-session的鉴权方式已经不适用于前后端分离项目了。在鉴权方面，有许多的实现方式，这篇文章不是来对比和介绍各个鉴权方式的优缺点，而是来普及其中之一-JWT。
更多文章，欢迎关注微信公众号：深夜程猿。
什么是JWT
JWT是JSON Web Token的缩写。 JSON Web Token（JWT）是一个开放标准（RFC 7519），它定义了一种紧凑且独立的方式，可以在各方之间作为JSON对象安全地传输信息。此信息可以通过数字签名进行验证和信任。 JWT可以使用加密算法（例如HMAC算法）或使用RSA或ECDSA的公钥/私钥对进行签名。 虽然JWT可以加密以在各方之间提供保密，但我们将专注于签名令牌。签名令牌可以验证其中包含的声明的完整性，而加密令牌则隐藏其他方的声明。当使用公钥/私钥对签署令牌时，签名还证明只有持有私钥的一方是签署私钥的一方。
JWT的结构
JWT由三部分组成，使用'.'号连接：
- Header部分 标头通常由两部分组成：令牌的类型，即JWT，以及正在使用的散列算法，例如HMAC SHA256或RSA。，比如
{ "alg": "HS256", "typ": "JWT" }表示使用了HS256来生成签名。Header部分会使用Base64Url编码设置到JWT的第一部分。 - Payload部分： 令牌的第二部分是有效负载，其中包含声明。声明是关于实体（通常是用户）和其他数据的声明。声明有三种类型：注册，公开和私有声明。
注册声明：这些是一组预定义的声明，它们不是强制性的，但是建议使用，以提供一组有用的，可互操作的声明。其中一些是：iss（发行人），exp（到期时间），sub（主题），aud（观众）等。
公开声明：这些可以由使用JWT的人随意定义。但是为避免冲突，应在IANA JSON Web令牌注册表中定义它们，或者将其定义为包含防冲突命名空间的URI。
私有声明：这些是为在同意使用它们的各方之间共享信息而创建的自定义声明，既不是注册声明也不是公开声明。
一个Payload示例：
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
复制代码Payload也会和Header一样Base64Url编码，放在JWT第二部分。
复制代码- Signature部分： 要创建签名部分，必须采用编码标头(Header)，编码的有效负载(Payload)，秘钥，标头中指定的算法，并对其进行签名。 例如，如果要使用HMAC SHA256算法，将按以下方式创建签名：
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
复制代码最后用'.'号把三个部分连接起来就完成了一个完整的JWT。
JWT的用途
认证
这是使用JWT的最常见场景。一旦用户登录，每个后续请求将包括JWT，允许用户访问该令牌允许的路由，服务和资源。 单点登录是一种现在广泛使用JWT的功能，因为它的开销很小，并且能够在不同的域中轻松使用
信息交换
JSON Web Token是在各方之间安全传输信息的好方法。因为JWT可以签名 - 例如，使用公钥/私钥对 - 您可以确定发件人是他们所说的人。此外，由于使用标头和有效负载计算签名，您还可以验证内容是否未被篡改。
JWT工作原理
在身份验证中，当用户使用其凭据成功登录时，将返回JSON Web令牌。由于令牌是凭证，因此必须非常小心以防止出现安全问题。一般情况下，您不应该将令牌保留的时间超过要求。 每当用户想要访问受保护的路由或资源时，用户代理应该使用承载模式发送JWT，通常在Authorization标头中。标题的内容应如下所示：
Authorization: Bearer <token>
复制代码在某些情况下，这可以是无状态授权机制。服务器的受保护路由将在Authorization标头中检查有效的JWT，如果存在，则允许用户访问受保护的资源。如果JWT包含必要的数据，则可以减少查询数据库以进行某些操作的需要，尽管可能并非总是如此。 如果在Authorization标头中发送令牌，则跨域资源共享（CORS）将不会成为问题，因为它不使用cookie。 下图显示了如何获取JWT并用于访问API或资源：
- 应用程序或客户端向授权服务器请求授权。这是通过其中一个不同的授权流程执行的。例如，典型的OpenID Connect兼容Web应用程序将使用授权代码流通过/ oauth / authorize端点。
- 授予授权后，授权服务器会向应用程序返回访问令牌。
- 应用程序使用访问令牌来访问受保护资源（如API）。 由于JWT会暴露给第三方和用户，所以在生成JWT的时候我们最好不要把用户隐私数据放进去。