「JWT」，你必须了解的认证登录方案

者：古时的风筝
原文链接：https://www.cnblogs.com/fengzheng/p/13527425.html

JWT 全称是 JSON Web Token，是目前非常流行的跨域认证解决方案，在单点登录场景中经常使用到。

有些人觉得它非常好用，用了它之后就不用在服务端借助 redis 实现认证过程了，但是，还有一部分人认为它生来就有缺陷，根本不能用。

这是为什么呢？

传统的认证方式

从一个登录场景说起

你平时用过那么多网站和 APP，其中有很多都是需要登录的吧，那咱们就选一个场景出来说说。

以一个电商系统为例，如果你想要下单，首先需要注册一个账号，拥有了账号之后，需要输入用户名（比如手机号或邮箱）、密码完成登录过程。之后你在一段时间内再次进入系统，是不需要输入用户名和密码的，只有在连续长时间不登录的情况下（例如一个月没登录过）访问系统，才需要再次输入用户名和密码。

对于那些使用频率很高的网站或应用，通常是很长时间都不需要输入密码的，以至于你在换了一台电脑或者一部手机之后，一些经常使用的网站或 APP 的密码都不记得了。

早期的 Cookie-Session 认证方式

早期互联网以 web 为主，客户端是浏览器，所以 Cookie-Session 方式是早期最常用的认证方式，直到现在，一些 web 网站依然用这种方式做认证。

认证过程大致如下：

用户输入用户名、密码或者用短信验证码方式登录系统；
服务端验证后，创建一个 Session 信息，并且将 SessionID 存到 cookie，发送回浏览器；
下次客户端再发起请求，自动带上 cookie 信息，服务端通过 cookie 获取 Session 信息进行校验；

但是为什么说它是传统的认证方式，因为现在人手一部智能手机，很多人都不用电脑，平时都是使用手机上的各种 APP，比如淘宝、拼多多等。
在这种潮流之下，传统的 Cookie-Session 就遇到了一些问题：
1、首先，Cookie-Session 只能在 web 场景下使用，如果是 APP 呢，APP 可没有地方存 cookie。
现在的产品基本上都同时提供 web 端和 APP 两种使用方式，有点产品甚至只有 APP。

2、退一万步说，你做的产品只支持 web，也要考虑跨域问题，但Cookie 是不能跨域的。
拿天猫商城来说，当你进入天猫商城后，会看到顶部有天猫超市、天猫国际、天猫会员这些菜单。而点击这些菜单都会进入不同的域名，不同的域名下的 cookie 都是不一样的，你在 A 域名下是没办法拿到 B 域名的 cookie 的，即使是子域也不行。

3、如果是分布式服务，需要考虑 Session 同步问题。
现在的互联网网站和 APP 基本上都是分布式部署，也就是服务端不止一台机器。当某个用户在页面上进行登录操作后，这个登录动作必定是请求到了其中某一台服务器上。你的身份信息得保存下来吧，传统方式就是存 Session。

接下来，问题来了。你访问了几个页面，这时，有个请求经过负载均衡，路由到了另外一台服务器（不是你登录的那台）。当后台接到请求后，要检查用户身份信息和权限，于是接口开始从从 Session 中获取用户信息。但是，这台服务器不是当时登录的那台，并没存你的 Session ，这样后台服务就认为你是一个非登录的用户，也就不能给你返回数据了。

所以，为了避免这种情况的发生，就要做 Session 同步。一台服务器接收到登录请求后，在当前服务器保存 Session 后，也要向其他几个服务器同步。

4、cookie 存在 CSRF（跨站请求伪造）的风险。跨站请求伪造，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。CSRF 利用的是网站对用户网页浏览器的信任。简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（比如购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户发起的操作。
比如说我是一个黑客，我发现你经常访问的一个技术网站存在 CSRF 漏洞。发布文章支持 html 格式，进而我在 html 中加入一些危险内容，例如

 <img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">

假设 src 指向的地址是一个你平时用的购物网站的付款地址（当然只是举例，真正的攻击可没这么简单），如果你之前登录过并且标识你身份信息的 cookie 已经保存下来了。当你刷到我发布的这篇文章的时候，img 标签一加载，这个 CSRF 攻击就会起作用，在你不知情的情况下向这个网站付款了。

Cookie-Session 改造版

由于传统的 Cookie-Session 认证存在诸多问题，那可以把上面的方案改造一下。
1、改造 Cookie 既然 Cookie 不能在 APP 等非浏览器中使用，那就不用 cookie 做客户端存储，改用其他方式。
改成什么呢？
web 中可以使用 local storage，APP 中使用客户端数据库，这样既能这样就实现了跨域，并且避免了 CSRF 。

2、服务端也不存 Session 了，把 Session 信息拿出来存到 Redis 等内存数据库中，这样即提高了速度，又避免了 Session 同步问题；

经过改造之后变成了如下的认证过程：

用户输入用户名、密码或者用短信验证码方式登录系统；
服务端经过验证，将认证信息构造好的数据结构存储到 Redis 中，并将 key 值返回给客户端；
客户端拿到返回的 key，存储到 local storage 或本地数据库；
下次客户端再次请求，把 key 值附加到 header 或者请求体中；
服务端根据获取的 key，到 Redis 中获取认证信息；

下面两张图分别演示了首次登录和非首次登录的过程。

经过一顿猛如虎的改造，解决了传统 Cookie-Session 方式存在的问题。这种改造需要开发者在项目中自行完成。改造起来肯定是费时费力的，而且还有可能存在漏洞。

JWT 出场

这时，JWT 就可以上场了，JWT 就是一种Cookie-Session改造版的具体实现，让你省去自己造轮子的时间，JWT 还有个好处，那就是你可以不用在服务端存储认证信息（比如 token），完全由客户端提供，服务端只要根据 JWT 自身提供的解密算法就可以验证用户合法性，而且这个过程是安全的。

如果你是刚接触 JWT，最有疑问的一点可能就是： JWT 为什么可以完全依靠客户端(比如浏览器端)就能实现认证功能，认证信息全都存在客户端，怎么保证安全性？

JWT 数据结构

JWT 最后的形式就是个字符串，它由头部、载荷与签名这三部分组成，中间以「.」分隔。像下面这样：

头部

头部以 JSON 格式表示，用于指明令牌类型和加密算法。形式如下，表示使用 JWT 格式，加密算法采用 HS256，这是最常用的算法，除此之外还有很多其他的。

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

对应上图的红色 header 部分，需要 Base64 编码。

载荷

用来存储服务器需要的数据，比如用户信息，例如姓名、性别、年龄等，要注意的是重要的机密信息最好不要放到这里，比如密码等。

{
  "name": "古时的风筝",
  "introduce": "英俊潇洒"
}

另外，JWT 还规定了 7 个字段供开发者选用。

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

这部分信息也是要用 Base64 编码的。

签名

签名有一个计算公式。

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

使用HMACSHA256算法计算得出，这个方法有两个参数，前一个参数是（base64 编码的头部 + base64 编码的载荷）用点号相连，后一个参数是自定义的字符串密钥，密钥不要暴露在客户端，而应该服务器知道。

使用方式

了解了 JWT 的结构和算法后，那怎么使用呢？假设我这儿有个网站。

1、在用户登录网站的时候，需要输入用户名、密码或者短信验证的方式登录，登录请求到达服务端的时候，服务端对账号、密码进行验证，然后计算出 JWT 字符串，返回给客户端。

2、客户端拿到这个 JWT 字符串后，存储到 cookie 或者浏览器的 LocalStorage 中。

3、再次发送请求，比如请求用户设置页面的时候，在 HTTP 请求头中加入 JWT 字符串，或者直接放到请求主体中。

4、服务端拿到这串 JWT 字符串后，使用 base64的头部和 base64 的载荷部分，通过HMACSHA256算法计算签名部分，比较计算结果和传来的签名部分是否一致，如果一致，说明此次请求没有问题，如果不一致，说明请求过期或者是非法请求。

怎么保证安全性的

保证安全性的关键就是 HMACSHA256 或者与它同类型的加密算法，因为加密过程是不可逆的，所以不能根据传到前端的 JWT 传反解到密钥信息。

另外，不同的头部和载荷加密之后得到的签名都是不同的，所以，如果有人改了载荷部分的信息，那最后加密出的结果肯定就和改之前的不一样的，所以，最后验证的结果就是不合法的请求。

别人拿到完整 JWT 还安全吗

假设载荷部分存储了权限级别相关的字段，强盗拿到 JWT 串后想要修改为更高权限的级别，上面刚说了，这种情况下是肯定不会得逞的，因为加密出来的签名会不一样，服务器可能很容易的判别出来。

那如果强盗拿到后不做更改，直接用呢，那就没有办法了，为了更大程度上防止被强盗盗取，应该使用 HTTPS 协议而不是 HTTP 协议，这样可以有效的防止一些中间劫持攻击行为。

有同学就要说了，这一点也不安全啊，拿到 JWT 串就可以轻松模拟请求了。确实是这样，但是前提是你怎么样能拿到，除了上面说的中间劫持外，还有什么办法吗？

除非强盗直接拿了你的电脑，那这样的话，对不起，不光 JWT 不安全了，其他任何网站，任何认证方式都不安全。

虽然这样的情况很少，但是在使用 JWT 的时候仍然要注意合理的设置过期时间，不要太长。

一个问题

JWT 有个问题，导致很多开发团队放弃使用它，那就是一旦颁发一个 JWT 令牌，服务端就没办法废弃掉它，除非等到它自身过期。有很多应用默认只允许最新登录的一个客户端正常使用，不允许多端登录，JWT 就没办法做到，因为颁发了新令牌，但是老的令牌在过期前仍然可用。这种情况下，就需要服务端增加相应的逻辑。

常用的 JWT 库

JWT 官网列出了各种语言对应的库，其中 Java 的如下几个。

以 java-jwt为例。

1、引入对应的 Maven 包。

<dependency>
    <groupId>com.auth0</groupId>
    <artifactId>java-jwt</artifactId>
    <version>3.10.3</version>
</dependency>

2、在登录时，调用 create 方法得到一个令牌，并返回给前端。

public static String create(){
  try {
    Algorithm algorithm=Algorithm.HMAC256("secret");
    String token=JWT.create()
      .withIssuer("auth0")
      .withSubject("subject")
      .withClaim("name","古时的风筝")
      .withClaim("introduce","英俊潇洒")
      .sign(algorithm);
    System.out.println(token);
    return token;
  } catch (JWTCreationException exception){
    //Invalid Signing configuration / Couldn't convert Claims.
    throw exception;
  }
}

3、登录成功后，再次发起请求的时候将 token 放到 header 或者请求体中，服务端对 token 进行验证。

public static Boolean verify(String token){
  try {
    Algorithm algorithm=Algorithm.HMAC256("secret");
    JWTVerifier verifier=JWT.require(algorithm)
      .withIssuer("auth0")
      .build(); //Reusable verifier instance
    DecodedJWT jwt=verifier.verify(token);
    String payload=jwt.getPayload();
    String name=jwt.getClaim("name").asString();
    String introduce=jwt.getClaim("introduce").asString();
    System.out.println(payload);
    System.out.println(name);
    System.out.println(introduce);
    return true;
  } catch (JWTVerificationException exception){
    //Invalid signature/claims
    return false;
  }
}

4、用 create 方法生成 token，并用 verify 方法验证一下。

public static void main(String[] args){
  String token=create();
  Boolean result=verify(token);
  System.out.println(result);
}

得到下面的结果

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJzdWJqZWN0IiwiaW50cm9kdWNlIjoi6Iux5L-K5r2H5rSSIiwiaXNzIjoiYXV0aDAiLCJuYW1lIjoi5Y-k5pe255qE6aOO562dIn0.ooQ1K_XyljjHf34Nv5iJvg1MQgVe6jlphxv4eeFt8pA
eyJzdWIiOiJzdWJqZWN0IiwiaW50cm9kdWNlIjoi6Iux5L-K5r2H5rSSIiwiaXNzIjoiYXV0aDAiLCJuYW1lIjoi5Y-k5pe255qE6aOO562dIn0
古时的风筝
英俊潇洒
true

使用 create 方法创建的 JWT 串可以通过验证。

而如果我将 JWT 串中的载荷部分，两个点号中间的部分修改一下，然后再调用 verify 方法验证，会出现 JWTVerificationException异常，不能通过验证。

关面试题如下：

什么是 JWT?为什么要用 JWT？
JWT 由哪些部分组成？
如何基于 JWT 进行身份验证？
JWT 如何防止 Token 被篡改？
如何加强 JWT 的安全性？
如何让 Token 失效？
......

什么是 JWT?

JWT （JSON Web Token）是目前最流行的跨域认证解决方案，是一种基于 Token 的认证授权机制。从 JWT 的全称可以看出，JWT 本身也是 Token，一种规范化之后的 JSON 结构的 Token。

Token 自身包含了身份验证所需要的所有信息，因此，我们的服务器不需要存储 Session 信息。这显然增加了系统的可用性和伸缩性，大大减轻了服务端的压力。

可以看出，JWT 更符合设计 RESTful API 时的「Stateless（无状态）」原则。

并且，使用 Token 认证可以有效避免 CSRF 攻击，因为 Token 一般是存在在 localStorage 中，使用 JWT 进行身份验证的过程中是不会涉及到 Cookie 的。

我在 JWT 优缺点分析[1]这篇文章中有详细介绍到使用 JWT 做身份认证的优势和劣势。

下面是 RFC 7519[2] 对 JWT 做的较为正式的定义。

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. ——JSON Web Token (JWT)[3]

JWT 由哪些部分组成？

JWT 本质上就是一组字串，通过（.）切分成三个为 Base64 编码的部分：

Header : 描述 JWT 的元数据，定义了生成签名的算法以及 Token 的类型。
Payload : 用来存放实际需要传递的数据
Signature（签名）：服务器通过 Payload、Header 和一个密钥(Secret)使用 Header 里面指定的签名算法（默认是 HMAC SHA256）生成。

JWT 通常是这样的：xxxxx.yyyyy.zzzzz。

示例：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

你可以在 jwt.io[4] 这个网站上对其 JWT 进行解码，解码之后得到的就是 Header、Payload、Signature 这三部分。

Header 和 Payload 都是 JSON 格式的数据，Signature 由 Payload、Header 和 Secret(密钥)通过特定的计算公式和加密算法得到。

Header

Header 通常由两部分组成：

typ（Type）：令牌类型，也就是 JWT。
alg（Algorithm）：签名算法，比如 HS256。

示例：

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

JSON 形式的 Header 被转换成 Base64 编码，成为 JWT 的第一部分。

Payload

Payload 也是 JSON 格式数据，其中包含了 Claims(声明，包含 JWT 的相关信息)。

Claims 分为三种类型：

Registered Claims（注册声明）：预定义的一些声明，建议使用，但不是强制性的。
Public Claims（公有声明）：JWT 签发方可以自定义的声明，但是为了避免冲突，应该在 IANA JSON Web Token Registry[5] 中定义它们。
Private Claims（私有声明）：JWT 签发方因为项目需要而自定义的声明，更符合实际项目场景使用。

下面是一些常见的注册声明：

iss（issuer）：JWT 签发方。
iat（issued at time）：JWT 签发时间。
sub（subject）：JWT 主题。
aud（audience）：JWT 接收方。
exp（expiration time）：JWT 的过期时间。
nbf（not before time）：JWT 生效时间，早于该定义的时间的 JWT 不能被接受处理。
jti（JWT ID）：JWT 唯一标识。

示例：

{
  "uid": "ff1212f5-d8d1-4496-bf41-d2dda73de19a",
  "sub": "1234567890",
  "name": "John Doe",
  "exp": 15323232,
  "iat": 1516239022,
  "scope": ["admin", "user"]
}

Payload 部分默认是不加密的，一定不要将隐私信息存放在 Payload 当中！！！

JSON 形式的 Payload 被转换成 Base64 编码，成为 JWT 的第二部分。

Signature

Signature 部分是对前两部分的签名，作用是防止 Token（主要是 payload）被篡改。

这个签名的生成需要用到：

Header + Payload。
存放在服务端的密钥(一定不要泄露出去)。
签名算法。

签名的计算公式如下：

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

算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用"点"（.）分隔，成为 JWT 的第三部分。

如何基于 JWT 进行身份验证？

在基于 Token 进行身份验证的的应用程序中，服务器通过 Payload、Header 和Secret(密钥)创建Token（令牌）并将 Token 发送给客户端。客户端接收到 Token 之后，会将其保存在 Cookie 或者 localStorage 里面，以后客户端发出的所有请求都会携带这个令牌。

简化后的步骤如下：

用户向服务器发送用户名、密码以及验证码用于登陆系统。
如果用户用户名、密码以及验证码校验正确的话，服务端会返回已经签名的 Token。
用户以后每次向后端发请求都在 Header 中带上这个 Token。
服务端检查 Token 并从中获取用户相关信息。

两点建议：

建议将 Token 存放在 localStorage 中，放在 Cookie 中会有 CSRF 风险。
请求服务端并携带 Token 的常见做法是将 Token 放在 HTTP Header 的 Authorization 字段中（Authorization: Bearer Token）。

spring-security-jwt-guide[6] 就是一个基于 JWT 来做身份认证的简单案例，感兴趣的可以看看。

JWT 如何防止 Token 被篡改？

有了签名之后，即使 Token 被泄露或者解惑，黑客也没办法同时篡改 Signature 、Header 、Payload。

这是为什么呢？因为服务端拿到 Token 之后，会解析出其中包含的 Header、Payload 以及 Signature 。服务端会根据 Header、Payload、密钥再次生成一个 Signature。拿新生成的 Signature 和 Token 中的 Signature 作对比，如果一样就说明 Header 和 Payload 没有被修改。

不过，如果服务端的秘钥也被泄露的话，黑客就可以同时篡改 Signature 、Header 、Payload 了。黑客直接修改了 Header 和 Payload 之后，再重新生成一个 Signature 就可以了。

密钥一定保管好，一定不要泄露出去。JWT 安全的核心在于签名，签名安全的核心在密钥。

如何加强 JWT 的安全性？

使用安全系数高的加密算法。
使用成熟的开源库，没必要造轮子。
Token 存放在 localStorage 中而不是 Cookie 中，避免 CSRF 风险。
一定不要将隐私信息存放在 Payload 当中。
密钥一定保管好，一定不要泄露出去。JWT 安全的核心在于签名，签名安全的核心在密钥。
Payload 要加入 exp （JWT 的过期时间），永久有效的 JWT 不合理。并且，JWT 的过期时间不易过长。
......

参考资料

[1]

JWT 优缺点分析: ./advantages&disadvantages-of-jwt.md

[2]

RFC 7519: https://tools.ietf.org/html/rfc7519

[3]

JSON Web Token (JWT): https://tools.ietf.org/html/rfc7519

[4]

jwt.io: https://jwt.io/

[5]

IANA JSON Web Token Registry: https://www.iana.org/assignments/jwt/jwt.xhtml

[6]

spring-security-jwt-guide: https://github.com/Snailclimb/spring-security-jwt-guide

言

本文内容来源于官方网站，让我们来了解下JWT

官网地址

https://jwt.io/

什么是JWT？

JWT是一个开放标准(RFC 7519)，完整的名称是JSON Web Token,以下都简称JWT,它是一种紧凑且独立的以JSON对象的形式在各种场景下安全地传输信息。因为它是数字签名的,可以对它进行验证。可以使用一个秘密对JWT进行签名(使用HMAC算法)或使用RSA或ECDSA。

什么时候应该使用JWT？

以下是一些适合使用JWT的场景：

授权

认证授权是使用JWT最常见的场景。一旦用户登录，每个后续请求都将包括JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是当今广泛使用的一种特性，因为它开销小，而且能够很容易在不同的域下使用，也就是我们常说的跨域。

信息交换

JWT是在各场景之间安全地传输信息的一种好方法。因为JWT可以进行签名，例如，使用公钥/私钥对，你可以根据公钥/私钥对来判断请求信息是否有效。此外，由于签名是使用报头和负载计算的，你还可以验证内容有没有被篡改。

JWT的结构

JWT以其紧凑的形式由点分隔的三个部分组成(.)，它们是：

Header（标头）
Payload（负载）
Signature（签名）

因此，JWT通常是下面这样的形势

Header.Payload.Signature

我们针对不同的部分别来介绍：

标头（Header）：

标头典型由两个部分组成：令牌的类型(即JWT)正在使用的签名算法(如HMAC SHA 256或RSA)。

例如：

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

负载（Payload）

令牌的第二部分是负载，它包含了以下部分：

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

除了官方提供的字段之外，你还可以自定义字段：

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

注意：对于签名的令牌，这些信息虽然受到保护，但任何人都可以阅读。除非加密，否则不要将秘密信息放入JWT的有效负载或头元素中，如登录密码等。

签名

要创建签名部分，你必须接受编码的头部、编码的负载、表头中的加密算法，并对其进行签名。

例如，如果要使用HMAC SHA 256算法，则将以下列方式创建签名：

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

签名用于验证消息在过程中没有被更改，对于用私钥签名的令牌，它还可以验证JWT的发送方是否是它所称的发送方。

Base64Url

生成的结果是三个Base64-URL字符串，由点分隔，可以在HTML和HTTP环境中轻松地传递，同时与基于XML的标准(如SAML)相比更加紧凑。

JWT是如何做到有效验证的？

在身份验证中，当用户成功地使用他们的凭据登录时，将返回一个JWT。由于令牌是凭据，因此必须非常小心地防止安全问题。通常，你不应将令牌保存的时间超过所需时间。

每当用户想访问受保护的路由或资源时，用户代理应该发送JWT，通常在请求头带上如下：

Authorization: Bearer <token>

在某些情况下，这可能是一种无状态授权机制。服务器的受保护路由将在授权标头，如果它存在，则允许用户访问受保护的资源。如果JWT包含必要的数据，那么查询数据库中某些操作的需求可能会减少，尽管情况可能并不总是这样。

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

应用程序或客户端向授权服务器请求授权。这是通过不同的授权流之一执行的。例如一个典型的OpenID连接兼容的web应用程序将通过/oauth/authorize端点使用授权码流.
当授权被授予时，授权服务器将访问令牌返回给应用程序。
应用程序使用访问令牌访问受保护的资源(如API)。
JWT通常可以存放在cookies或者localStorage中

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

总结一下

JWT在当前的Web或HTTP应用开发中非常受用，本文通过介绍JWT能让我们更容易的理解什么是JWT，以及如何使用，并且JWT的工作原理，JWT针对各个平台都有对应的多个可选框架使用，因此在理解了JWT的结构和原理之后，我们可以更加简单的使用它，如果本文对你有帮助，请麻烦帮忙转发、点赞加关注哦！谢谢！

在线咨询

上一篇：投票启动！请为你喜爱的 “新时代的春联”打call
下一篇：WindSNS谈运营垂直SNS网站的九大经验！》

您的项目需求

*请认真填写需求信息，我们会在24小时内与您取得联系。

整合营销服务商