使用JWT生成Token令牌

使用JWT生成Token令牌

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

JWT能做什么？

• 授权
  这是使用JWT的最常见的方案，一旦用户登陆，每个后续请求将包括JWT，从而允许用户访问该令牌的路由，服务和资源。单点登陆是当今广泛使用JWT的一项功能，因为他的开销很小，并且可以在不同的域中轻松使用。

• 信息交换

  JSON Web Token是在各方之间安全地传输信息的好方法，因为可以对JWT进行签名（例如：使用公钥/私钥对），所以您可以确保发件人是他们所说的人。此外，由于签名是使用标头和有效负载计算的，因此您还可以验证内容是否被篡改。

传统Session和JWT认证方式

传统Session认证方式

我们知道，http协议本身是一种无状态的协议，而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，那么下一次请求时，用户还要再一次进行用户认证才行，因为根据http协议，我们并不能知道是哪个用户发出的请求，所以为了让我们的应用能识别是哪个用户发出的请求，我们只能在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为cookie,以便下次请求时发送给我们的应用，这样我们的应用就能识别请求来自哪个用户了,这就是传统的基于session认证。

客户端—>服务器（创建会话，保存当前登陆对象）----响应（携带sessionid以cookie的形式）–>客户端

但是这种基于session的认证使应用本身很难得到扩展，随着不同客户端用户的增加，独立的服务器已无法承载更多的用户，而这时候基于session认证应用的问题就会暴露出来.

暴露问题：

• **压力增加：**通常session都是保存在内存中，随着认证用户的增多，服务端的开销会明显增大
• 无法在分布式系统上认证：因为如果用户的登陆认证被记录到当前服务器中那么下次请求就必须访问认证时的服务器才可以
• 安全风险高，因为是基于cookie来进行识别的，cookie如果被截取，用户就会很容易收到跨站请求伪造攻击，不建议使用前后端分离：通常用户一次请求就要转发多次，如果使用session每次携带sessionid到服务器，服务器查询用户信息。同时如果用户很多，这些存在服务器内存中，给服务器造成一定的压力。还有就是CSRF（跨站伪造攻击），session是基于cookie进行用户识别的，cookie容易被截获，用户就很容易受到跨站请求伪造攻击。还有就是sessionid就是一个特征值，表达的信息不够丰富，不容易扩展。而且如果后端应用的是多节点部署，那么就需要实现session共享机制。不方便集群应用

JWT认证方式

认证流程：

• 首先，前端通过web表单将自己的用户名和密码发送到后端接口。这一过程就是http post请求。建议的方式是通过SSL加密协议传输（https），从而避免被嗅探。

• 后端对用户名和密码验证成功后，将用户的id等信息作为JWT Plyload(负载)，将其与头部分别进行Base64编码拼接后签名，形成一个JWT（token）。

• 后端将JWT字符串作为登陆成功的返回结果返回给前端。前端可以将返回的结果保存在localStorage或sessionStorage上，退出登陆时将前端保存的JWT删除即可

• 后端检查是否存在，如存在验证jwt的有效性。例如，检查签名是否正确，检查token是否过期；检查token的接收方是否是自己

• 验证通过后后端使用JWT中包含的用户信息进行其他逻辑操作，返回相应结果

JWT的优势：

• 简洁：可以通过url，post参数或者http header发送，数据量小，传输速度快
• 自包含（Self-contained）：负载中包含了所有用户需要的信息，避免了多次查询数据库
• 因为Token是以JSON加密的形式保存在客户端的，所以JWT是跨语言的，原则上任何web形式都支持
• 不需要在服务端保存会话信息，特比适合用于分布式微服务

JWT结构

JWT结构由令牌组成：header.playload.signature 即 标头、有效载荷、签名

表头（Header）：

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

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

负载（Payload）：

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

签名（Signature）：

前面两个部分都是使用Base64进行编码的，即前端可以解开知道里面的信息。Signature需要使用编码后的header和payload以及我们提供的一个密钥，然后使用header中指定的签名算法进行签名、签名的作用是保证jwt没有被篡改过

Base64是一种编码，是可逆的，所以敏感信息不建议放入jwt中

如何使用JWT

封装JWT工具类

public class JWTUtil {

    private static final String SIGN = "!^&%&*!@$*%!!@(&%2ar^2t";

    /**
     * 生成Token
     */
    public static String getToken(Map<String,String> map){
        JWTCreator.Builder builder = JWT.create();
        Calendar instance = Calendar.getInstance();
        instance.add(Calendar.DATE,7);//过期时间默认为7七天
        map.forEach((k,v)->{
            builder.withClaim(k,v);
        });
        return builder.withExpiresAt(instance.getTime()).sign(Algorithm.HMAC256(SIGN));
    }

    /**
     * 验证token
     */
    public static DecodedJWT verify(String token){
        return JWT.require(Algorithm.HMAC256(SIGN)).build().verify(token);
    }


}

常见异常信息：

• AlgorithmMismatchException：算法出现错误，例：加密使用HMAC256 解密使用HMAC384
• SignatureVerificationException：签名不一致，例：签名：1234 验签：1111
• TokenExpiredException：token失效
• InvalidClaimException：失效的payload异常