基于JWT的token身份认证方案

使用JSON Web Token的好处

性能问题

验证信息可以由前端保存,后端不需要为保存token消耗内存。JWT方式将用户状态分散到了客户端中,相比于Session,可以明显减轻服务端的内存压力。
Session方式存储用户id的最大弊病在于Session是存储在服务器端的,所以需要占用大量服务器内存,对于较大型应用而言可能还要保存许多的状态,一般还需借助nosql和缓存机制来实现Session存储,如果是分布式应用还需Session共享。

单点登录

JWT能轻松的实现单点登录,因为用户的状态已经被传送到了客户端。
token 可保存自定义信息,如用户基本信息,web服务器用key去解析token,即可获取到请求用户的信息。
我们也可以配置它以便包含用户拥有的任何权限。这意味着每个服务不需要与授权服务交互就能授权用户。

前后端分离

以前的传统模式下,后台对应的客户端就是浏览器,就可以使用session+cookies的方式实现登录。
但是在前后分离的情况下,后端只负责通过暴露的RestApi提供数据,而页面的渲染、路由都由前端完成。因为rest是无状态的,因此也就不会有Session记录到服务器端。

兼容性

支持移动设备,支持跨程序调用,Cookie 是不允许垮域访问的,而 Token 则不存在这个问题。

可拓展性

JWT是无状态的,特别适用于分布式站点的单点登录(SSO)场景。
比如有3台机器(A、B、C)组成服务器集群,若Session存在机器A上,Session只能保存在其中一台服务器,此时你便不能访问机器B、C,因为B、C上没有存放该Session,
而使用token就能够验证用户请求合法性,并且我再加几台机器也没事,所以可拓展性好。

安全性

因为有签名,所以JWT可以防止被篡改,而且加密支持多种算法。

JSON Web Token是什么

JWT是基于token的身份认证的方案

json web token全称。可以保证安全传输的前提下传送一些基本的信息,以减轻对外部存储的依赖,减少了分布式组件的依赖,减少了硬件的资源。

实现无状态、分布式的Web应用授权,jwt的安全特性保证了token的不可伪造和不可篡改。

本质上是一个独立的身份验证令牌,可以包含用户标识、用户角色和权限等信息,以及您可以存储任何其他信息(自包含)。任何人都可以轻松读取和解析,并使用密钥来验证真实性。

缺陷:

(1)JWT在生成token的时候支持失效时间,但是支持的失效时间是固定的,比如说一天。
但是用户登出是随机触发的,那么JWT token来做这个失效是不可行的,因为JWT在初始化时已经定死过期时间。可采用其他方案,在redis中存储token,设置token的过期时间,每次鉴权的时候都会去延长时间
(2)JWT不适合存放大量信息,信息越多token越长

JWT就是一个字符串,经过加密处理与校验处理的字符串,形式为:

1
A.B.C

.连接,分别是头部、载荷、签名。A由JWT头部信息header加密得到,B由JWT用到的身份验证信息json数据加密得到,C由A和B加密得到,是校验部分

头部部分header

用于描述关于该JWT的最基本的信息,例如其类型以及签名所用的算法等。这也可以被表示成一个JSON对象。

1
2
3
4
{
"alg": "HS256",
"typ": "JWT"
}

alg描述的是签名算法。默认值是HS256。将header用base64加密,得到A。

  • HS256:对称算法加密
  • RS256:非对称算法加密

载荷部分payload

其实就是自定义的数据,一般存储用户Id,过期时间等信息。也就是JWT的核心所在,因为这些数据就是使后端知道此token是哪个用户已经登录的凭证。而且这些数据是存在token里面的,由前端携带,所以后端几乎不需要保存任何数据。

1
2
3
4
5
6
7
8
9
10
{
"iss": "发行者",
"sub": "主题",
"aud": "观众",
"exp": "过期时间",
"iat": "签发时间",
//以下可以添加自定义数据
"id": "1",
"nickname": "昵称"
}

根据JWT claim set[用base64]加密得到的。claim set是一个json数据,是表明用户身份的数据,可自行指定字段很灵活,也有固定字段表示特定含义(但不一定要包含特定字段,只是推荐)。
Base64算法是可逆的,不可以在载荷部分保存用户密码等敏感信息。如果业务需要,也可以采用对称密钥加密。

签名部分signature

HMACSHA256(Base64(Header) + "." + Base64(Payload), secret),secret是加密的盐。
签名的目的是用来验证头部和载荷是否被非法篡改。

验签过程描述:获取token值,读取Header部分并Base64解码,得到签名算法。根据以上方法算出签名,如果签名信息不一致,说明是非法的。

JSON Web Token工作原理

  1. 初次登录:用户初次登录,输入用户名密码
  2. 密码验证:服务器从数据库取出用户名和密码进行验证
  3. 生成JWT:服务器端验证通过,根据从数据库返回的信息,以及预设规则,生成JWT
  4. 返回JWT:服务器的将token放在cookie中将JWT返回
  5. 带JWT的请求:以后客户端发起请求,带上cookie中的token信息

JWT+Redis的登录方案流程:

  • 前端服务器收到用户登录请求,传给后台API网关
  • API网关把请求分发到用户服务里进行身份验证
  • 后台用户服务验证通过,然后从账号信息抽取出userName、login_time等基本信息组成payload,进而组装一个JWT,把JWT放入redis(因为退出时无法使jwt立即作废,所以使用保存在redis中,退出的时候delete掉即可,鉴权时加一层判断JWT是否在redis里,如果不在则证明JWT已过期作废),然后包装到cookie中返回到前端服务器,即登录成功
  • 前端服务器拿到JWT,进行存储(可以存储在缓存中,也可以存储在数据库中,如果是浏览器,可以存储在cookie或localStorage中)
  • 登录后,再访问其他微服务时,前端会携带JWT访问后台,后台校验 JWT,验签通过后,返回相应资源和数据即可

代码实现

Maven依赖

1
2
3
4
5
6
7
8
9
<dependency>
<groupId>com.auth0</groupId>
<artifactId>java-jwt</artifactId>
</dependency>
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt</artifactId>
</dependency>
`

生成Token和验证Token

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
public class JwtUtils {
/**
* 签发JWT
* @param id
* @param subject 可以是JSON数据 尽可能少
* @param ttlMillis
* @return String
*
*/
public static String createJWT(String id, String subject, long ttlMillis) {
SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;
long nowMillis = System.currentTimeMillis();
Date now = new Date(nowMillis);
SecretKey secretKey = generalKey();
JwtBuilder builder = Jwts.builder()
.setId(id)
.setSubject(subject) // 主题
.setIssuer("user") // 签发者
.setIssuedAt(now) // 签发时间
.signWith(signatureAlgorithm, secretKey); // 签名算法以及密匙
if (ttlMillis >= 0) {
long expMillis = nowMillis + ttlMillis;
Date expDate = new Date(expMillis);
builder.setExpiration(expDate); // 过期时间
}
return builder.compact();
}

/**
* 验证JWT
* @param jwtStr
* @return
*/
public static CheckResult validateJWT(String jwtStr) {
CheckResult checkResult = new CheckResult();
Claims claims = null;
try {
claims = parseJWT(jwtStr);
checkResult.setSuccess(true);
checkResult.setClaims(claims);
} catch (ExpiredJwtException e) {
checkResult.setErrCode(SystemConstant.JWT_ERRCODE_EXPIRE);
checkResult.setSuccess(false);
} catch (SignatureException e) {
checkResult.setErrCode(SystemConstant.JWT_ERRCODE_FAIL);
checkResult.setSuccess(false);
} catch (Exception e) {
checkResult.setErrCode(SystemConstant.JWT_ERRCODE_FAIL);
checkResult.setSuccess(false);
}
return checkResult;
}

public static SecretKey generalKey() {
byte[] encodedKey = Base64.decode(SystemConstant.JWT_SECERT);
SecretKey key = new SecretKeySpec(encodedKey, 0, encodedKey.length, "AES");
return key;
}

/**
*
* 解析JWT字符串
* @param jwt
* @return
* @throws Exception
*/
public static Claims parseJWT(String jwt) throws Exception {
SecretKey secretKey = generalKey();
return Jwts.parser()
.setSigningKey(secretKey)
.parseClaimsJws(jwt)
.getBody();
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class LoginController {
@Autowired
UserRepository userRepository;

@ApiOperation(value="用户登陆")
@RequestMapping(value="login", method = RequestMethod.POST)
public ReturnVo login(String username, String password, HttpServletResponse response) {
User user = userRepository.findByUsername(username);
if (user != null) {
if (user.getPassword().equals(password)) {
//把token返回给客户端-->客户端保存至cookie-->客户端每次请求附带cookie参数
String jwt = JwtUtils.createJWT(user.getId(), username, SystemConstant.JWT_TTL);
return ReturnVo.ok(jwt);
} else {
return ReturnVo.error();
}
} else {
return ReturnVo.error();
}
}
}

Powered by AppBlog.CN     浙ICP备14037229号

Copyright © 2012 - 2020 APP开发技术博客 All Rights Reserved.

访客数 : | 访问量 :