了解JWT“令牌”

JWT学习笔记

1、什么是JWT

JSON Web Token（JWT）是一种开放标准（RFC 7519），它定义了一种紧凑且自包含的方式，用于在各方之间以JSON对象的形式安全地传输信息。此信息可以被验证和信任，因为它是数字签名的。JW T可以使用秘密（使用HMAC算法）或使用RSA或ECDSA的公钥/私钥对进行签名。

2、JWT能够做什么

授权

使用JWT最常见的场景。

用户登录后，每个后续请求都将包含JWT，允许用户访问该令牌所允许的路由、服务和资源。因为它的开销很小，并且能够很容易地跨不同的域使用。

签名策略

JWT采用签名策略保证了请求发送者的token令牌未被篡改

3、为什么是JWT

3.1、传统的基于Session认证

认证流程

1. 用户首次登录成功并将用户信息保存到Session中（）
2. http协议本身是一种无状态的协议：用户成功登录之后继续发送后续业务请求，但是由于角色权限，用户每次发送后续请求都需要从Session中取出对应的用户信息来判断当前登录用户是否具有执行该业务的权限
3. 但是将用户信息存放到Session中，而Session基于内存存储一般都存储在服务器端，是想这种场景有什么缺陷：
   • 如果服务器集群部署该web项目，那么如何保存当前登录的用户信息，每一台服务器都复制一份用户信息？

存在的问题

1. 每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以方便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大
2. 用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上，这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。
3. 因为是基于cook1e来进行用户识别的，cook1e如果被截获，用户就会很容易受到跨站请求伪造的攻击。（什么叫跨站请求伪造？）
4. 在前后端分离系统中就更加痛苦：也就是说前后端分离在应用解耦后增加了部署的复杂性。通常用户一次请求就要转发多次。如果用session每次携带sessionid到服务器，服务器还要查询用户信息。同时如果用户很多。这些信息存储在服务器内存中，给服务器增加负担。还有就是CSF(跨站伪造请求攻击)攻击，session是基于cookie进行用户识别的，cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。还有就是sessionid就是一个特征值，表达的信息不够丰富。不容易扩展。而且如果你后端应用是多节点部署。那么就需要实现session共享机制。
5. 不方便集群应用。

3.2、JWT认证

认证流程

1. 首先用户登录
2. 后端核对用户名和密码成功后，将用户的id等其他信息作为JWT Payload(负载)，将其与头部分别进行Base64编码拼接后签名，形成-个JWT(Token)。形成的JWT就是-个形同xxx.yyy.zzz的字符串,token==》head.payload.singurater
3. 后端将JWT字符串作为登录成功的返回结果返回给前端。前端可以将返回的结果保存在localStorage或sessionStorage.上，退出登录时前端删除保存的JWT即可。
4. 前端在每次请求时将JWT放入HTTP Header中的Authorization位。（解决XSS和XRF问题）
5. 后端检查是否存在，如存在验证JWT的有效性。例如，检查签名是否正确；检查Token是否过期；检查Token的接收方是否是自己

优点

• 简洁(Compact):可以通过URL,PoST参数或者在HTTP header发送，因为数据量小，传输速度也很快

• 自包含(Self-contained):负载中包含了所有用户所需要的信息，避免了多次查询数据库

• 因为Token是以JSON加密的形式保存在客户端的，所以JWT是跨语言的，原则上任何web形式都支持。

• 不需要在服务端保存会话信息，特别适用于分布式微服务。

4、JWT结构组成

标头(Header)

• 标头通常由两部分组成：令牌的类型（即JWT)和所使用的签名算法，例如HMAC SHA256或RSA。它会使用BaSe64编码组成JWT结构的第一部分。

• 注意：Base64是一种编码，也就是说，它是可以被翻译回原来的样子来的。它并不是一种加密过程。

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

有效载荷(Pay1oad)

• 令牌的第二部分是有效负载，其中包含声明。声明是有关实体（通常是用户）和其他数据的声明。同样的，它会使用BaS64编码组成JWT结构的第二部分

• {
    "name":"matengfei",
    "age":"22",
    "phone":"110"
  }
  

签名(Signature)

• 前面两部分都是使用Base64进行编码的，即前端可以解开知道里面的信息。Signature需要使用编码后的header和payload以及我们提供的一个密钥，然后使用header中指定的签名算法(HS256)进行签名。签名的作用是保证JWT没有被篡改过
• 例如：HMACSHA256(base64UrlEncode(header)+“.”+base64UrlEncode(payload),secret);
• 签名目的：最后一步签名的过程，实际上是对头部以及负载内容进行签名，防止内容被窜改。如果有人对头部以及负载的内容解码之后进行修改，再进行编码，最后加上之前的签名组合形成新的JWT的话，那么服务器端会判断出新的头部和负载形成的签名和JWT附带上的签名是不一样的。如果要对新的头部和负载进行签名，在不知道服务器加密时用的密钥的话，得出来的签名也是不一样的。

信息安全问题

在这里大家一定会问一个问题：Base64是一种编码，是可逆的，那么我的信息不就被暴露了吗？
是的。所以，在JWT中，不应该在负载里面加入任何敏感的数据。在上面的例子中，我们传输的是用户的User ID。这个值实际上不是什么敏感内容，一般情况下被知道也是安全的。但是像密码这样的内容就不能被放在JWT中了。如果将用户的密码放在了JWT中，那么怀有恶意的第三方通过Bse64解码就能很快地知道你的密码了。因此JWT适合用于向Wb应用传递一些非敏感信息。JWT还经常用于设计用户认证和授权系统，甚至实现Web应用的单点登录

5、java客户端测试

5.1、步骤

• 引入依赖

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

• 创建jwt（token令牌）

  /*
      * 生成Token令牌
      * */
  @Test
  public void generateToken(){
    Calendar calendar = Calendar.getInstance();
    calendar.add(Calendar.SECOND,120);
  
    //创建一个token
    String token = JWT.create()
      //设置负载信息
      .withClaim("username","matengfei")
      .withClaim("age",22)
  
      //令牌设置过期时间（什么时候过期）
      .withExpiresAt(calendar.getTime())
  
      //设置密钥，并指定以哪种算法来加密
      .sign(Algorithm.HMAC256("@matengfei"));
  
    System.out.println(token);
  }
  

• 解析jwt（解析token，一般取出负载信息）

  /*
      * 解析JWT
      * */
  @Test
  public void parseToken(){
    String token = "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE2NzI0NTA1MTYsImFnZSI6MjIsInVzZXJuYW1lIjoibWF0ZW5nZmVpIn0.aStqDWUA9m66ucsfqjU4V2v53u8eJKzsmPpWt9vh1r8";
    JWTVerifier jwtVerifier = JWT.require(Algorithm.HMAC256("@matengfei")).build();
  
    DecodedJWT decodedJWT = jwtVerifier.verify(token);
    System.out.println(decodedJWT);
  
    System.out.println("用户名："+decodedJWT.getClaim("username").asString());
    System.out.println("用户年龄："+decodedJWT.getClaim("age").asInt());
    System.out.println("token过期时间为："+decodedJWT.getExpiresAt());
  }
  

  ​

5.1、常见异常与信息

• 签名不一致
• 令牌过期
• 算法不匹配
• 失效的pagload

6、复习

• @ResponseBody注解底层是jackson
• 拦截器重写的三个方法
• ​