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.baidu.com">

假设 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 为什么可以完全依靠客户端(比如浏览器端)就能实现认证功能，认证信息全都存在客户端，怎么保证安全性？

WT 数据结构

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 令牌，服务端就没办法废弃掉它，除非等到它自身过期。有很多应用默认只允许最新登录的一个客户端正常使用，不允许多端登录，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 instanceDecodedJWT 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/claimsreturn false;}
}

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


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

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

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

JWT 新一代认证登录方案相关推荐

OAuth2+JWT新一代认证技术
OAuth2四种认证模式,授权许可是表示客户用来获取访问令牌的资源所有者授权的凭证.此规范协议规定了4种授权类型: authorization code(授权码模式) 用户访问客户端,客户端通过用户代 ...
『JWT』，你必须了解的认证登录方案
我是风筝,公众号「古时的风筝」,全栈工程师,bug 杀手. 文章会收录在 JavaNewBee 中,更有 Java 后端知识图谱,从小白到大牛要走的路都在里面. 知识地图传统的认证方式从一个登录场 ...
SpringBoot 快速集成 JWT 实现用户登录认证
前言:当今前后端分离时代,基于Token的会话保持机制比传统的Session/Cookie机制更加方便,下面我会介绍SpringBoot快速集成JWT库java-jwt以完成用户登录认证. 一.JWT ...
用户的登陆认证、DjangoRestFramework JWT多条件登录,导航栏实现
用户的登陆认证.DjangoRestFramework JWT&多条件登录 Django REST framework JWT JWT介绍 JWT的构成生成规则: header payloa ...
魔方APP项目-06-用户注册，完成短信验证码的校验、基于Celery实现短信异步发送、用户登录，jwt登陆认证、服务端提供用户登录的API接口
一.用户注册- 1.完成短信验证码的校验 application.utils.language.message,代码: class ErrorMessage():ok = "ok" ...
肝！一文讲解JWT用户认证全过程
什么是JWT(what) JWT(JSON Web Token)是一个开放标准(RFC 7519),它定义了一种紧凑且自包含的方式,以JSON对象的形式在各方之间安全地传输信息. JWT是一个数字签名 ...
分布式认证-技术方案
根据选型的分析,决定采用基于token的认证方式,它的优点是: 1.适合统一认证的机制,客户端.一方应用.三方应用都遵循一致的认证机制. 2.token认证方式对第三方应用接入更适合,因为它更开放, ...
认证授权方案之JwtBearer认证
1.前言回顾:认证方案之初步认识JWT 在现代Web应用程序中,即分为前端与后端两大部分.当前前后端的趋势日益剧增,前端设备(手机.平板.电脑.及其他设备)层出不穷.因此,为了方便满足前端设备与后端 ...
微服务商城系统（十） Spring Security Oauth2 + JWT 用户认证
文章目录一.用户认证分析 1.认证与授权 2.单点登录 3.第三方账号登录 4.第三方认证 5.认证技术方案 6.Security Oauth 2.0 入门 7. 资源服务授权 (1)资源服务授 ...

JWT 新一代认证登录方案