JWT的原理及实际应用

 前言：

定义：JSON Web Token（缩写 JWT）是目前最流行的跨域认证解决方案

JWT官网

由于HTTP协议是无状态的，这意味着如果我们想判定一个接口是否被认证后访问，就需要借助cookie或者session会话机制进行判定，但是由于现在的系统架构大部分都不止一台服务器，此时又要借助数据库或者全局缓存 做存储，这种方案显然受限太多。

那么我们可不可以让认证令牌的发布者自己去识别这个令牌是不是我曾经发布的令牌呢（JWT核心思想），这是JWT最大的优点也是最大的缺点，优点是简单快捷、不需要依赖任何第三方操作就能实现身份认证，缺点就是对于任何拥有用户发布令牌的请求都会认证通过。

1.  JWT是什么

JSON Web Token (JWT)是一个开放标准(RFC 7519)，它定义了一种紧凑的、自包含的方式，用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它是数字签名的。

2. 什么时候你应该用JWT

下列场景中使用JSON Web Token是很有用的：

• Authorization (授权) : 这是使用JWT的最常见场景。一旦用户登录，后续每个请求都将包含JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是现在广泛使用的JWT的一个特性，因为它的开销很小，并且可以轻松地跨域使用。
• Information Exchange (信息交换) : 对于安全的在各方之间传输信息而言，JSON Web Tokens无疑是一种很好的方式。因为JWTs可以被签名，例如，用公钥/私钥对，你可以确定发送人就是它们所说的那个人。另外，由于签名是使用头和有效负载计算的，您还可以验证内容没有被篡改。

3. JWT的结构是什么样的

JSON Web Token由三部分组成，它们之间用圆点(.)连接。这三部分分别是：

• Header
• Payload
• Signature

因此，一个典型的JWT看起来是这个样子的：

Header.Payload.Signature

接下来，具体看一下每一部分：

Header

header典型的由两部分组成：token的类型（“JWT”）和算法名称（比如：HMAC SHA256或者RSA等等）。

例如：

然后，用Base64对这个JSON编码就得到JWT的第一部分

Payload

JWT的第二部分是payload，它包含声明（要求）。声明是关于实体(通常是用户)和其他数据的声明。声明有三种类型: registered, public 和 private。

• Registered claims : 这里有一组预定义的声明，它们不是强制的，但是推荐。比如：iss (issuer), exp (expiration time), sub (subject), aud (audience)等。
• Public claims : 可以随意定义。
• Private claims : 用于在同意使用它们的各方之间共享信息，并且不是注册的或公开的声明。

Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据。JWT 规定了7个官方字段，供选用。

• iss (issuer)：签发人
• exp (expiration time)：过期时间
• sub (subject)：主题
• aud (audience)：受众
• nbf (Not Before)：生效时间
• iat (Issued At)：签发时间
• jti (JWT ID)：编号

除了官方字段，你还可以在这个部分定义私有字段，下面就是一个例子。

对payload进行Base64编码就得到JWT的第二部分

注意，不要在JWT的payload或header中放置敏感信息，除非它们是加密的。

Signature

为了得到签名部分，你必须有编码过的header、编码过的payload、一个秘钥，签名算法是header中指定的那个，然对它们签名即可。

例如：

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

签名是用于验证消息在传递过程中有没有被更改，并且，对于使用私钥签名的token，它还可以验证JWT的发送方是否为它所称的发送方。

看一张官网的图就明白了：

4. JWT是如何工作的

在认证的时候，当用户用他们的凭证成功登录以后，一个JSON Web Token将会被返回。此后，token就是用户凭证了，你必须非常小心以防止出现安全问题。一般而言，你保存令牌的时候不应该超过你所需要它的时间。

无论何时用户想要访问受保护的路由或者资源的时候，用户代理（通常是浏览器）都应该带上JWT，典型的，通常放在Authorization header中，用Bearer schema。

header应该看起来是这样的：

Authorization: Bearer <token>

服务器上的受保护的路由将会检查Authorization header中的JWT是否有效，如果有效，则用户可以访问受保护的资源。如果JWT包含足够多的必需的数据，那么就可以减少对某些操作的数据库查询的需要，尽管可能并不总是如此。

如果token是在授权头（Authorization header）中发送的，那么跨源资源共享(CORS)将不会成为问题，因为它不使用cookie。

下面这张图显示了如何获取JWT以及使用它来访问APIs或者资源：

1. 应用（或者客户端）想授权服务器请求授权。例如，如果用授权码流程的话，就是/oauth/authorize
2. 当授权被许可以后，授权服务器返回一个access token给应用
3. 应用使用access token访问受保护的资源（比如：API）

4.1JWT原理

JWT全称JSON Web Token。当服务器认证成功后会生成一个Token，这个token包含了header、payload、signature三部分信息。其中payload的内容有过期时间、签发时间、还有自定义的字段。自定义字段往往用来存放用户信息，比如UserId，UserName等等信息。当客户端收到这个token后存储在Cookie，localstorage或者别的什么地方并且以后每次请求都带上token。服务端对请求所携带的token进行解析，判断是否过期是否合法。

​

以上简单的描述了下JWT的工作原理，因为jwt的payload携带了过期时间、用户信息等，所以JWT有别于传统Session方案的一个最大不同就是JWT是无状态的，JWT不用在内存或DB里维持session的状态，直接拿到token解析就可以了。

原理图：

​

4.2 JWT 的几个特点

（1）JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。

（2）JWT 不加密的情况下，不能将秘密数据写入 JWT。

（3）JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低