者：古时的风筝

原文链接：https://www.cnblogs.com/fengzheng/p/13527425.html

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

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

这是为什么呢？

传统的认证方式

从一个登录场景说起

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

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

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

早期的 Cookie-Session 认证方式

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

认证过程大致如下：

1. 用户输入用户名、密码或者用短信验证码方式登录系统；
2. 服务端验证后，创建一个 Session 信息，并且将 SessionID 存到 cookie，发送回浏览器；
3. 下次客户端再发起请求，自动带上 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 同步问题；

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

1. 用户输入用户名、密码或者用短信验证码方式登录系统；
2. 服务端经过验证，将认证信息构造好的数据结构存储到 Redis 中，并将 key 值返回给客户端；
3. 客户端拿到返回的 key，存储到 local storage 或本地数据库；
4. 下次客户端再次请求，把 key 值附加到 header 或者 请求体中；
5. 服务端根据获取的 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异常，不能通过验证。

ession简介#

做过Web开发的程序员应该对Session都比较熟悉，Session是一块保存在服务器端的内存空间，一般用于保存用户的会话信息。

用户通过用户名和密码登陆成功之后，服务器端程序会在服务器端开辟一块Session内存空间并将用户的信息存入这块空间，同时服务器会
在cookie中写入一个Session_id的值，这个值用于标识这个内存空间。

下次用户再来访问的话会带着这个cookie中的session_id，服务器拿着这个id去寻找对应的session，如果session中已经有了这个用户的
登陆信息，则说明用户已经登陆过了。

使用Session保持会话信息使用起来非常简单，技术也非常成熟。但是也存在下面的几个问题：

• 服务器压力大：通常Session是存储在内存中的，每个用户通过认证之后都会将session数据保存在服务器的内存中，而当用户量增大时，服务器的压力增大。
• Session共享：现在很多应用都是分布式集群，需要我们做额外的操作进行Session共享；
• CSRF跨站伪造请求攻击：Session机制是基于浏览器端的cookie的，cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。

基于token的认证#

基于token的认证机制将认证信息返回给客户端并存储。下次访问其他页面，需要从客户端传递认证信息回服务端。简单的流程如下：

• 客户端使用用户名跟密码请求登录；
• 服务端收到请求，去验证用户名与密码；
• 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端；
• 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里；
• 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token；
• 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据；

基于token的验证机制，有以下的优点：

• 支持跨域访问，将token置于请求头中，而cookie是不支持跨域访问的；
• 无状态化，服务端无需存储token，只需要验证token信息是否正确即可，而session需要在服务端存储，一般是通过cookie中的sessionID在服务端查找对应的session；
• 无需绑定到一个特殊的身份验证方案（传统的用户名密码登陆），只需要生成的token是符合我们预期设定的即可；
• 更适用于移动端（Android，iOS，小程序等等），像这种原生平台不支持cookie，比如说微信小程序，每一次请求都是一次会话，当然我们可以每次去手动为他添加cookie，详情请查看博主另一篇博客；
• 避免CSRF跨站伪造攻击，还是因为不依赖cookie；

缺点的话一个就是相比较于传统的session登陆机制实现起来略微复杂一点，另外一个比较大的缺点是由于服务器不保存 token，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 token 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。

退出登陆的话，只要前端清除token信息即可。

基于JWT的token认证实现#

JWT（JSON Web Token）就是基于token认证的代表，这边就用JWT为列来介绍基于token的认证机制。

需要引入JWT的依赖

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

生成token和验证token的工具类如下：

public class JWTTokenUtil {
    //设置过期时间
    private static final long EXPIRE_DATE=30*60*100000;
    //token秘钥
    private static final String TOKEN_SECRET = "ZCfasfhuaUUHufguGuwu2020BQWE";

    public static String token (String username,String password){

        String token = "";
        try {
            //过期时间
            Date date = new Date(System.currentTimeMillis()+EXPIRE_DATE);
            //秘钥及加密算法
            Algorithm algorithm = Algorithm.HMAC256(TOKEN_SECRET);
            //设置头部信息
            Map<String,Object> header = new HashMap<>();
            header.put("typ","JWT");
            header.put("alg","HS256");
            //携带username，password信息，生成签名
            token = JWT.create()
                    .withHeader(header)
                    .withClaim("username",username)
                    .withClaim("password",password).withExpiresAt(date)
                    .sign(algorithm);
        }catch (Exception e){
            e.printStackTrace();
            return  null;
        }
        return token;
    }

    public static boolean verify(String token){
        /**
         * @desc   验证token，通过返回true
         * @params [token]需要校验的串
         **/
        try {
            Algorithm algorithm = Algorithm.HMAC256(TOKEN_SECRET);
            JWTVerifier verifier = JWT.require(algorithm).build();
            DecodedJWT jwt = verifier.verify(token);
            return true;
        }catch (Exception e){
            e.printStackTrace();
            return  false;
        }
    }
    public static void main(String[] args) {
        String username ="name1";
        String password = "pw1";
        //注意，一般不会把密码等私密信息放在payload中，这边只是举个列子
        String token = token(username,password);
        System.out.println(token);
        boolean b = verify(token);
        System.out.println(b);
    }
}

执行结果如下：

Connected to the target VM, address: '127.0.0.1:11838', transport: 'socket'
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXNzd29yZCI6IjEyMyIsImV4cCI6MTU5NzM5Nzc0OCwidXNlcm5hbWUiOiJ6aGFuZ3NhbiJ9.LI5S_nX-YcqtExI9UtKiP8FPqpQW_ccaws2coLzyOS0
true

关于DecodedJWT这个类，大家可以重点看下，里面包含了解码后的用户信息。

JWT的使用说明#

客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。

此后，客户端每次与服务器通信，都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP 请求的头信息Authorization字段里面。

Authorization: Bearer <token>

另一种做法是，跨域的时候，JWT 就放在 POST 请求的数据体里面。

JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。

为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。（或者是对JWT在前后端之间进行加密之后在传输）

关于JWT的一个问题#

上面生成JWT token的过程关键点就是密钥，假如这个密钥泄露了，那是不是就可以伪造token了。

还有就是生产环境的密钥值，开发的程序员大概率是知道的，怎么防止程序要监守自盗，伪造token值呢？希望有经验的大佬指教下。

//token秘钥
private static final String TOKEN_SECRET = "ZCfasfhuaUUHufguGuwu2020BQWE";

关于上面的问题，@仙湖码农 给出了一个简单易懂的方案~

jwt 来生成token，还有一个玩法，用户登录时，生成token的 SecretKey 是一个随机数，也就是说每个用户，每次登录时jwt SecretKey 是随机数，并保存到缓存，key是登录账户，（当然了，分布式缓存的话，就用Redis，sqlserver缓存等等），总之，客户端访问接口是，header 要带登录账户，和token，服务端拿到登录账号，到缓存去捞相应的SecretKey ，然后再进行token校验。可以防伪造token了（这个方案在一定程度上能防止伪造，但是不能防止token泄露被劫持）。

获取refresh token的方法#

• https://www.cnblogs.com/wyt007/p/11459547.html

常生活中，访问https网页时会提示“与此网站是安全链接”，网站部署了SSL证书也会有证书颁发机构信息，浏览器根证书受信，加密安全等等提示，表示访问的网页是受到数据加密，安全性网站。浏览器验证SSL或TLS证书的过程是为了确保与网站之间的通信是安全的。SSL/TLS证书用于加密数据传输，防止中间人攻击，并验证网站的身份。那么浏览器是如何对SSL证书进行验证呢？

1、获取证书：

当用户尝试访问一个使用HTTPS的网站时，浏览器首先会向服务器发送一个连接请求。服务器响应这个请求并提供其SSL/TLS证书。如未部署SSL证书，通常会提示“您与该网站的连接不是私密连接，存在安全隐患。”

2、检查证书链：

SSL证书通常由一个证书颁发机构（CA）签名。证书中包含了公钥、域名和颁发者的信息。浏览器会检查证书的签名是否来自一个受信任的CA，以及该证书是否适用于所请求的网站。

以国产SSL证书品牌JoySSL申请为例，打开JoySSL官网，选择需要的证书类型（单域名、多域名、通配符、IP证书、代码签名证书等等），在验签后，按步骤提示完成在服务器中的部署就可以了。

打开JoySSL官网，填写注册码230921，即可免费获得SSL证书。

https://www.joyssl.com/certificate/select/free.html?nid=21

3、验证签名：

浏览器使用CA的公钥来验证证书的数字签名。如果签名有效，这意味着证书没有被篡改过，且确实是由CA签发的。

4、检查有效期：

SSL证书有有效期，过期的证书将被视为无效。浏览器会检查证书的有效开始日期和结束日期，确保当前日期在有效期内。如证书未部署上或者证书有效期时间已过，也会有证书过期或者非安全链接等等提示。

5、检查域名匹配：

证书中包含的域名必须与用户正在访问的网站域名相匹配。例如，如果你访问的是www.baidu.com，那么证书中的域名也应该是www.baidu.com或baidu.com。

6、检查黑名单：

浏览器会检查证书是否在任何已知的黑名单中，以避免使用已被撤销的证书。

7、建立安全连接：

如果上述所有检查都通过，浏览器和服务器之间将进行密钥交换，以创建一个安全的、加密的数据通道。这通常涉及选择加密算法、生成会话密钥等步骤。常用的是国际算法，能适用目前市场上主流浏览器，也有部分教务、政务机构有特殊要求。

8、警告和错误：

如果在验证过程中发现任何问题，比如证书无效、域名不匹配或已过期，浏览器将显示警告信息或阻止用户访问该网站，以保护用户的隐私和数据安全。