签发的用户认证token超时刷新策略

签发的用户认证token超时刷新策略

这个模块分离至上上上上一篇api权限管理系统与前后端分离实践，感觉那样太长了找不到重点，分离出来要好点。

---

对于登录的用户签发其对应的jwt，我们在jwt设置他的固定有效期时间，在有效期内用户携带jwt访问没问题，当过有效期后jwt失效，用户需要重新登录获取新的jwt。这个体验不太好，好的体验应该是：活跃的用户应该在无感知的情况下在jwt失效后获取到新的jwt，携带这个新的jwt进行访问，而长时间不活跃的用户应该在jwt失效后需要进行重新的登录认证。

这里就涉及到了token的超时刷新问题，解决方案看图：

在签发有效期为 t 时间的jwt后，把jwt用（“JWT-SESSION-”+appId,jwt）的key-value形式存储到redis中，有效期设置为2倍的 t 。这样jwt在有效期过后的 t 时间段内可以申请刷新token。
还有个问题是用户携带过期的jwt对后台请求，在可刷新时间段内返回了新的jwt，应该在用户无感知的情况下返回请求的内容，而不是接收一个刷新的jwt。我们是不是可以在每次request请求回调的时候判断返回的是不是刷新jwt，但是判断是之后我们是否放弃之前的用户请求，如果不放弃，那是不是应该在最开始的用户request请求前先保存这个请求，在之后的回调中如果是返回刷新jwt，我们再携带这个新的jwt再请求一次保存好的request请求？但对于前端这么大量的不同请求，这样是不是太麻烦了？

这困扰了我很久哎，直到我用到了angualr的HttpInterceptor哈哈哈哈哈哈哈哈哈哈哈哈哈哈。

angualr的HttpInterceptor就是前端的拦截过滤器,发起请求会拦截处理,接收请求也会拦截处理。最大的好处对每次的原始request他都会完整的保存下来，我们向后台发生的request是他的clone。next.handle(request.clone)
继承HttpInterceptor的AuthInterceptor，拦截response判断是否为refresh token，是则携带新token再次发起保存的request：

@Injectable()
export class AuthInterceptor implements HttpInterceptor {

  constructor(private authService: AuthService, private router: Router) {}

  intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    const authToken = this.authService.getAuthorizationToken();
    const uid = this.authService.getUid();
    let authReq: any;
    if (authToken != null && uid != null) {
      authReq = req.clone({
        setHeaders: {
          'authorization': authToken,