【SSO】JWT协议示例

转：http://www.iteedu.com/arch/sso/jwt.htm

JSON Web Token是什么

JSON Web Token (JWT)是一个开放标准(RFC 7519)，它定义了一种紧凑的、自包含的方式，用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它是数字签名的。

什么时候你应该用JSON Web Tokens

下列场景中使用JSON Web Token是很有用的：

Authorization (授权) : 这是使用JWT的最常见场景。一旦用户登录，后续每个请求都将包含JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是现在广泛使用的JWT的一个特性，因为它的开销很小，并且可以轻松地跨域使用。

Information Exchange (信息交换) : 对于安全的在各方之间传输信息而言，JSON Web Tokens无疑是一种很好的方式。因为JWTs可以被签名，例如，用公钥/私钥对，你可以确定发送人就是它们所说的那个人。另外，由于签名是使用头和有效负载计算的，您还可以验证内容没有被篡改。

JSON Web Token的结构是什么样的

JSON Web Token由三部分组成，它们之间用圆点(.)连接。这三部分分别是：

Header
Payload
Signature

因此，一个典型的JWT看起来是这个样子的：

xxxxx.yyyyy.zzzzz

接下来，具体看一下每一部分：

Header

header典型的由两部分组成：token的类型（“JWT”）和算法名称（比如：HMAC SHA256或者RSA等等）。

例如：

{"typ":"JWT","alg":"HS512"}

然后，用Base64对这个JSON编码就得到JWT的第一部分

Payload

JWT的第二部分是payload，它包含声明（要求）。声明是关于实体(通常是用户)和其他数据的声明。声明有三种类型: registered, public 和 private。

Registered claims : 这里有一组预定义的声明，它们不是强制的，但是推荐。比如：iss (issuer), exp (expiration time), sub (subject), aud (audience)等。

Public claims : 可以随意定义。

Private claims : 用于在同意使用它们的各方之间共享信息，并且不是注册的或公开的声明。

下面是一个例子：

{"sub":"026a564bbfd84861ac4b65393644beef","iat":1558597028,"exp":1559201828}

对payload进行Base64编码就得到JWT的第二部分

注意，不要在JWT的payload或header中放置敏感信息，除非它们是加密的。

Signature

为了得到签名部分，你必须有编码过的header、编码过的payload、一个秘钥，签名算法是header中指定的那个，然对它们签名即可。

例如：

HMACSHA512(base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret)

签名是用于验证消息在传递过程中有没有被更改，并且，对于使用私钥签名的token，它还可以验证JWT的发送方是否为它所称的发送方。

登录示例

登录过程：

1. 验证用户名和密码
2. 生成token
3. 返回token和过期时间

验证用户名密码要根据业务来。

生成token方法如下：

   public String generateToken(String userId) {
        Date nowDate = new Date();
        //过期时间
        Date expireDate = new Date(nowDate.getTime() + expire * 1000);

        return Jwts.builder()
                .setHeaderParam("typ", "JWT")
                .setSubject(userId)//主题，也差不多是个人的一些信息
                .setIssuedAt(nowDate) //创建时间
                .setExpiration(expireDate)//添加Token过期时间
                //.setAudience(audience) //个人签名
                //.setIssuer(issuer) //发送谁
                .signWith(SignatureAlgorithm.HS512, secret)
                .compact();
    }

生成token结果：

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJzdWIiOiIwMjZhNTY0YmJmZDg0ODYxYWM0YjY1MzkzNjQ0YmVlZiIsImlhdCI6MTU1ODU5NzAyOCwiZXhwIjoxNTU5MjAxODI4fQ.ePnFkWzqRYA_XeP1lOsbr_ZKJtXFIIBqofszn3A47t1uyZYvFmhOIJI3r7ziAKjFwIml-f9zX50YbhOWIrWOPA

用base64解密后如下：

header每次的token都一样，如下：

{“typ”:“JWT”,“alg”:“HS512”}

body每次会变，因为iat创建时间和exp过期时间每次会变：

{“sub”:“026a564bbfd84861ac4b65393644beef”,“iat”:1558597028,“exp”:1559201828}

访问验证

token在生成返回给客户端，以后客户端每个请求要在http header上带上，所有需要被验证的接口都从header上取出token，用如下方法验证：

//验证token
Claims claims = jwtUtils.getClaimByToken(token);
 if(claims == null || jwtUtils.isTokenExpired(claims.getExpiration())){
            throw new MyException("凭证失效，请重新登录");
}

    public Claims getClaimByToken(String token) {
        try {
            return Jwts.parser()
                    .setSigningKey(secret)
                    .parseClaimsJws(token)
                    .getBody();
        }catch (Exception e){
            logger.debug("token验证错误,请重新登陆 ", e);
            return null;
        }
    }

核心逻辑

token的核心在于签名，是通过下面设置实现的：

signWith(SignatureAlgorithm.HS512, secret)

这里有的hamc，再加个密码盐。

对一个字符串，用hamc(string+secret)得到的hash值为签名。

因为secret这个字符串只有自己知道，所以别人是生成不了一个字符串的签名的。

这种签名逻辑就保证了token只有自己发出去的才有效，别人伪造不了。

安全问题

因为token是在请求中明文传的，所以如果不用https协议，别人可以获取到。

这样别人就可以用token访问服务了。

所以token和传输一定要保证安全，不加密一定用https。