【SSO】JWT协议示例

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看起来是这个样子的:

1
xxxxx.yyyyy.zzzzz

接下来,具体看一下每一部分:

Header

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

例如:

1
{"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 : 用于在同意使用它们的各方之间共享信息,并且不是注册的或公开的声明。

下面是一个例子:

1
{"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方法如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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结果:

1
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,用如下方法验证:

1
2
3
4
5
6

//验证token
Claims claims = jwtUtils.getClaimByToken(token);
if(claims == null || jwtUtils.isTokenExpired(claims.getExpiration())){
throw new MyException("凭证失效,请重新登录");
}
1
2
3
4
5
6
7
8
9
10
11
public Claims getClaimByToken(String token) {
try {
return Jwts.parser()
.setSigningKey(secret)
.parseClaimsJws(token)
.getBody();
}catch (Exception e){
logger.debug("token验证错误,请重新登陆 ", e);
return null;
}
}

核心逻辑

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

1
signWith(SignatureAlgorithm.HS512, secret)

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

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

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

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

安全问题

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

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

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