JWT

json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

传统的session认证

我们知道，http协议本身是一种无状态的协议，而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，那么下一次请求时，用户还要再一次进行用户认证才行，因为根据http协议，我们并不能知道是哪个用户发出的请求，所以为了让我们的应用能识别是哪个用户发出的请求，我们只能在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为cookie,以便下次请求时发送给我们的应用，这样我们的应用就能识别请求来自哪个用户了,这就是传统的基于session认证。
但是这种基于session的认证使应用本身很难得到扩展，随着不同客户端用户的增加，独立的服务器已无法承载更多的用户，而这时候基于session认证应用的问题就会暴露出来.

基于session认证所显露的问题

  1. Session: 每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以方便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。
  2. 扩展性: 用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。

  3. CSRF: 因为是基于cookie来进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。

    基于token的鉴权机制

    基于token的鉴权机制类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。
    流程上是这样的：

  4. 用户使用用户名密码来请求服务器

  5. 服务器进行验证用户的信息
  6. 服务器通过验证发送给用户一个token
  7. 客户端存储token，并在每次请求时附送上这个token值

  8. 服务端验证token值，并返回数据

    JWT长什么样？

    JWT是由三段信息构成的，将这三段信息文本用.链接一起就构成了Jwt字符串。就像这样:

    1. eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

    JWT的构成

    第一部分我们称它为头部（header),第二部分我们称其为载荷（payload, 类似于飞机上承载的物品)，第三部分是签证（signature).

  9. header
    jwt的头部承载两部分信息：
    声明类型，这里是jwt
    声明加密的算法 通常直接使用 HMAC SHA256
    完整的头部就像下面这样的JSON：

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

  10. 然后将头部进行base64加密（该加密是可以对称解密的),构成了第一部分.

    eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

  11. playload载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品，这些有效信息包含三个部分:

    1. 标准中注册的声明
      iss: jwt签发者
      sub: jwt所面向的用户
      aud: 接收jwt的一方
      exp: jwt的过期时间，这个过期时间必须要大于签发时间
      nbf: 定义在什么时间之前，该jwt都是不可用的.
      iat: jwt的签发时间
      jti: jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。
    2. 公共的声明
      公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密
    3. 私有的声明
      私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。
      定义一个payload:

      {
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
      然后将其进行base64加密，得到Jwt的第二部分:
      eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

  12. signature
    jwt的第三部分是一个签证信息，这个签证信息由三部分组成：
    header (base64后的)
    payload (base64后的)
    secret: 加盐
    这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。
    将这三部分用.连接成一个完整的字符串,构成了最终的jwt:

    eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

  13. 注意：secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。

    JWT总结

  14. 优点
    · 因为json的通用性，所以JWT是可以进行跨语言支持的，像JAVA,JavaScript,NodeJS,PHP等很多语言都可以使用。
    · 因为有了payload部分，所以JWT可以在自身存储一些其他业务逻辑所必要的非敏感信息。
    · 便于传输，jwt的构成非常简单，字节占用很小，所以它是非常便于传输的。
    · 它不需要在服务端保存会话信息, 所以它易于应用的扩展

  15. 安全相关
    · 不应该在jwt的payload部分存放敏感信息，因为该部分是客户端可解密的部分。
    · 保护好secret私钥，该私钥非常重要。
    · 如果可以，请使用https协议

    使用 JJWT

    jjwt是java用来生成以及解析jwt的工具

  16. 导包

    <dependency>
 <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-api</artifactId>
    <version>0.11.2</version>
</dependency>
<dependency>
 <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-impl</artifactId>
 <version>0.11.2</version>
 <scope>runtime</scope>
</dependency>
<dependency>
 <groupId>io.jsonwebtoken</groupId>
 <artifactId>jjwt-jackson</artifactId> <!-- or jjwt-gson if Gson is preferred -->
 <version>0.11.2</version>
 <scope>runtime</scope>
</dependency>

  17. 生成与解析

    public class JwtUtil {
 //自定义的秘钥
 static String sect = "laisdjfoiwqjflksaasfdasdfadsfwfrasdfsadffcasijfasadfasfdlkfjlasjflksajfd";
    //生成token
 public static String createToken(Map<String, Object> body,Integer mil) {
     Key key = Keys.hmacShaKeyFor(sect.getBytes());
     return Jwts.builder()
            .setClaims(body)
            .setExpiration(new Date(System.currentTimeMillis() + mil * 60 * 1000))
            .signWith(key)
            .compact();
     }
 //解析token
 public static Claims parseToken(String token) {
     Key key = Keys.hmacShaKeyFor(sect.getBytes());
     return Jwts.parserBuilder().setSigningKey(key).build().parseClaimsJws(token).getBody();
 }
}

    token在服务间的传递

    实际项目的过程当中，前端请求携带token如果在header里面，这里会导致一个问题，在后端第一个服务可以成功提取出token，这个时候该服务有可能还会通过Feign或者RestTemplate去调用另外一个服务，后面的服务也有可能继续发起对其他服务调用，这种情况如果第一个服务部显示的再发请求的时候继续携带token在header里面，后面的服务就取不到token，为了解决这个问题而又不需要每次手动来添加token，我们可以使用Feign以及RestTemplate的拦截器来解决。

  18. Feign的拦截器

    @Component
public class TokenInterceptor implements RequestInterceptor{
 @Override
 public void apply(RequestTemplate template) {
     ServletRequestAttributes sra =                            
                 (ServletRequestAttributes)RequestContextHolder.getRequestAttributes();
     String token = sra.getRequest().getHeader("X-Token");
     if(token != null && !token.trim().equals("")) template.header("X-Token", token);    
 }
}

  19. RestTemplate拦截器

    @Component
public class TokenRestTemplateInterceptor implements ClientHttpRequestInterceptor{
 @Override
 public ClientHttpResponse intercept(HttpRequest request, byte[] body, ClientHttpRequestExecution                                 execution)throws IOException {
     ServletRequestAttributes sra =     
                 (ServletRequestAttributes)RequestContextHolder.getRequestAttributes();
     String token = sra.getRequest().getHeader("X-Token");
     if(token != null && !token.trim().equals("")) request.getHeaders().add("X-Token", token);
     return execution.execute(request, body);
 }
}

  20. 注意：template的拦截器需要手动添加到对象里面:

    @Bean
@LoadBalanced
public RestTemplate getRestTemplate() {
 RestTemplate rt = new RestTemplate();
 rt.setInterceptors(Arrays.asList(new TokenRestTemplateInterceptor()));
 return rt;
}