场景描述
- 笔者的项目架构采用的是springsecurity+jwt+oauth2.0架构,配置的多客户端校验权限获取jwt访问系统资源。
- 也就是说系统存在web,小程序,手机号三个用户体系,对应三个用户主表。
- 每个客户端在BaseClientDetails的access_token_validity和refresh_token_validity配置jwt的access_token和refresh_token的过期时间。
- 如下图:
- 读取数据库配置的客户端各字段属性,在上面的方法的中配置
- 如下图在配置类中注入自定义的客户端,以此来达到各个客户端用户登录的过期时间分开定义。
- 当然有人会说也可以在tokenService中定义过期策略,这个方法可行但是是全局的无法针对客户端分开配置。
- 然而,配置项都正常配置了,实际测试却发现过期时间的实际效果与设置的始终不对,后来又发现不是完全对不上,是对上了一半。接下来就看看源代码里面发生了什么。
源码查看
- 网上的帖子基本上都围绕OAuth2AuthenticationManager#authenticate方法来解读,但是这个方法只解读了token本身的合法性和客户端,权限范围scope等。
- 在tokenServices.loadAuthentication(token),此方法里的readAccessToken对token进行了解密和过期校验,此处的校验笔者推测是校验配置在全局(上面提到的)里的过期时间。理由:调试期间在另一个方法校验了过期,并且返回客户端了过期提示,OAuth2AuthenticationManager的方法都没有走。
- 由此可见校验基于客户端的过期策略,会在OAuth2AuthenticationManager#authenticate方法这之前校验。在时间校验通过后才会在这里详细的校验权限范围和token的签名等。
经过调试发现
在JwtReactiveAuthenticationManager#authenticate方法里进行了客户端token的解析校验。
由于是maven里的jar不能写注释,故此处大概写下流程:
- JwtReactiveAuthenticationManager#authenticate先是从authentication获取了加密的token,继而使用ReactiveJwtDecoder jwtDecoder去解析它.
- NimbusReactiveJwtDecoder#decode方法调用JWTParser.parse(token)解出明文成JWT。
- NimbusReactiveJwtDecoder#decode调用validateJwt方法验证解析出来的JWT
- 如上图validate校验JWT有四个实现类,这意味着有多个维度的校验,我们只看时间戳的校验(即过期时间的校验)
- 下图中有关键的一步minus(this.clockSkew),此处的clockSkew字面翻译时钟偏移,这意味着springsecurity在校验过期时间的时候会在当前时间上减去这个时间偏移,默认是60秒,再和你设定的应该过期的时间点比较。计算后的时间节点如果在你设定的时间之后才会进入if,返回token失效。(例如,当前时间8:00,你设定一分钟过期,实际判定需要等到8:02才会返回token失效)。
版权归原作者 hero_is_me 所有, 如有侵权,请联系我们删除。