随着互联网技术的发展，cookie+session形式的用户认真逐渐不适应需求的扩展。在当前分布式微服务广泛流行的场景下，显然这种cookie+session无法满足，因为各个服务之间无法相互获取session信息。这里可能有人说使用redis来存储session信息，达到session共享等等其他方式，但是总是不能够保证这个共享的地方能够供所有服务调用，如果出现了第三方系统，就无法满足需求了。所以cookie+session的形式是有一定的局限性的。
由此产生了其他的权限验证方式，我们先来看一下JWT（Json Web Token）形式。先来看一下JWT权限验证的基础逻辑：
那么什么是JWT，JWT长什么样，JWT能干什么？我们主要围绕这3个问题来思考。
1）JWT是什么？
JSON Web Token （JWT） 是一个开放标准 （RFC 7519），它定义了一种紧凑且自包含的方式，用于将信息安全地作为 JSON 对象在各方之间传输信息。此信息可以验证和信任，因为它是数字签名。JWT 可以使用密钥（使用HMAC算法）或使用 RSA 或 ECDSA 进行公钥/私钥对进行签名。
虽然可以加密 JWT 以在各方之间提供保密性，但我们将重点介绍已签名的令牌。签名令牌可以验证其中包含声明的完整性，而加密令牌则隐藏其他方声明。当使用公钥/私钥对对签名令牌时，签名还证明只有持有私钥的一方才是签名者。
2）JWT能干什么？
- 授权：这是使用 JWT 的最常见方案。用户登录后，每个后续请求都将包括 JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是当今广泛使用 JWT 的一项功能，因为它的开销小，并且能够轻松地跨不同域使用。
- 信息交换：JSON 网络令牌是各方之间安全传输信息的一种好方式。由于可以对JWT进行签名（例如，使用公钥/私钥对）可以确定发件人就是他们说的发件人。此外，由于使用标头和有效负载计算签名，您还可以验证内容是否未被篡改。
3）JWT长什么样？
JSON Web Token由三部分组成，它们之间用圆点(.)连接。这三部分分别是：
- Header
- Payload
- Signature
因此，一个典型的JWT看起来是这个样子的：
xxxxx.yyyyy.zzzzz
Header：
通常由两部分组成：令牌的类型（即 JWT）和正在使用的签名算法，如 HMAC SHA256 或 RSA。
例如：
{
"alg": "HS256",
"typ": "JWT"
}
然后，此 JSON编码为 Base64Url，以形成 JWT 的第一部分。
Payload
token的第二部分是payload，其中包含claims。claims是关于实体（通常为用户）和其他扩展数据。有三种类型的claims：registered、public 和 private。
-
Registered claims：这些是一组预定义claims，不是强制性的，但建议提供一组有用的、可互操作的claims。其中一些是：iss（发行人）、exp（到期时间）、sub（主题）、aud（受众）和其他
请注意，claims名称只有三个字符，只要 JWT 是紧凑的。
-
Public claims：这些可以由使用JWT的人可以当即定义。但是，为了避免冲突，应在IANA JSON Web 令牌注册表中定义它们，或定义为包含抗冲突命名空间的 URI。
-
Private claims：这些是为在同意使用它们的各方之间共享信息而创建的自定义声明，它们既不是已注册的，也不是公开声明。
示例：
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
然后对payload进行 Base64Url编码，以形成 JSON Web 令牌的第二部分。
Signature
为了得到签名部分，你必须有编码过的header、编码过的payload、一个秘钥，签名算法是header中指定的那个，然对它们签名即可。
例如：
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
签名是用于验证消息在传递过程中有没有被更改，并且，对于使用私钥签名的token，它还可以验证JWT的发送方是否为它所称的发送方。
4）JSON 网络令牌如何工作？
在Authentication（身份验证）中，当用户使用其凭据成功登录时，将返回 jwt，此后token是凭据，因此必须非常小心地防止安全问题。通常，不应将令牌保留的时间超过所需时间。
由于缺乏安全性，您也不应将敏感的会话数据存储在浏览器存储中。
每当用户想要访问受保护的路由或资源时，用户代理应发送 JWT，通常使用header中Authorization属性，用Bearer schema。标头的内容应如下所示：
Authorization: Bearer <token>
在某些情况下，这可能是一种无状态授权机制。服务器的受保护路由将在header中检查有效的 JWT，如果存在，则允许用户访问受保护的资源。如果 JWT 包含必要的数据，则查询数据库某些操作所需的需求可能会减少，但情况可能并非总是如此。Authorization
如果在header的Authorization中发送令牌，则跨源资源共享 （CORS） 不会成为问题，因为它不使用 Cookie。
下图显示了如何获取和用于访问 API 或资源：
- 应用程序或客户端向授权服务器请求授权。这通过一个不同的授权流执行。例如，典型的OpenID Connect 兼容应用程序将使用授权代码流通过终结点。
/oauth/authorize - 授予授权后，授权服务器将返回应用程序的访问令牌。
- 应用程序使用访问令牌访问受保护的资源（如 API）。
请注意，使用已签名的令牌时，令牌中包含的所有信息都公开给用户或其他方，即使他们无法更改这些信息。这意味着您不应将机密信息放在令牌中。
5）Jwt和session又有什么区别？
session的信息是存放在服务端的，cookie只是记录了一个sessionId。而jwt信息是存在在客户端的，服务器只是对token做验证，服务器是不记录任何用户信息的。也就有了最上面的token验证流程，这里面token办法服务器和校验服务器之间是不存在交互的。
Authorization Server只是验证完账号密码之后，根据一定的规则颁发token给用户客户端，以后所有的访问客户端都要携带这个token。这里面多数都会出现跨域问题，所以服务端需要允许跨域请求用Access-Control-Allow-Origin: * 或者指定域名可以访问Access-Control-Allow-Origin: "https://*.comeon4eyes.com"。