JWT token 实践问题解决

目录

一 token 接口改造

二  token 有效期可配

三 上课期间 token 不过期

四 老版本 APP 不崩溃

五 密码变更，token 失效

六 颁发、续约 token 接口安全性

七 token 签发可控

八 token 认证接口压测

---

JWT 实现 token 认证讲述了 JWT一些基本概念，使用JWT token 的优缺点以及使用需要注意的问题。本章主要讲述在使用 JWT token 过程中遇到的问题以及解决方案。

一 token 接口改造

token 是什么？token 是用户登录的时候颁发的。

改造场景：内网有一些接口是通过 token 来获取用户信息，这个是不合理的。

我的理解： token 是用来认证用户的，应该在外网之间进行流转；内网之间流转的应该是各种业务 id。

解决方案：获取用户信息应该使用 user_id。既然能拿到 token，说明 token 经过了认证服务，那认证服务会返回 user_id。

二  token 有效期可配

我们在生成 access_token、refresh_token 的时候会设置有效期，假设 access_token 有效期为2小时，refresh_token 为24小时。测试人员在测试功能的时候总不能等待

2小时或者24小时吧，那如何来解决，有效期太长的问题呢？为了提高测试效率，做成 access_token、refresh_token 都是可配置的，比如说1分钟过期、5分钟过期都是可以的。

三 上课期间 token 不过期

公司有一个业务场景是学生上课，那如何保证学生上课期间 token 失效、退登的情况不会发生？一旦发生 token 失效、退登的情况很容易导致用户体验差，产生各种投诉。

产生这种问题的根本的原因是上课期间 token 失效，针对这种情况我们只需要保证 token 在上课期间不会失效就行了，比如我们可以设置 token 失效时间为凌晨。凌晨孩子都睡了。

四 老版本 APP 不崩溃

在颁发 JWT token 的时候，会出现 JWT token、老 token 同时存在的问题；且 JWT token 有续约流程，老 token 是没有的。由于 APP 登录使用的是 h5 页面，如果颁发 JWT token，

一旦 JWT token 过期，走续约流程，APP 很容易崩溃。如何能够保证 APP 不崩溃呢？只需要保证 APP 老版本颁发老 token、新版本颁发 JWT token。那如何保证呢？由于登录是 h5 

页面，前端做版本控制，后端配合前端下发 JWT token、老 token，也就是说前端告诉我下发 JWT token，我就下发 JWT token；前端告诉我下发老 token，我就下发老 token。

五 密码变更，token 失效

由于 JWT token 是分布式的，也就是说如果不做其他的事情的话，密码变更，JWT token 是不会生效的。那如何能保证密码变更，JWT token 失效呢？

一开始的假设是将密码放置到 JWT token 的 payload 里面，这种方式相当于密码暴露到外面有一定的风险。后来想着是在 JWT token 里面添加密码变更时间戳，什么意思呢？

假设说今天给用户颁发的 JWT token 版本是 v1，明天用户修改了密码，之后登录版本的 JWT token 版本是 v2，则 v2 之前的版本 v1 都将失效。如此，才能做到密码变更， JWT token 失效。

六 颁发、续约 token 接口安全性

颁发 token、续约 token 两个接口属于敏感接口，如何能够保证这两个接口的安全性？或者说调用这两个接口是需要白名单的。

这块我们使用了接口的 API 签名和验签机制。只有特定的服务才能调用我们的颁发 token、续约 token 两个接口。

七 token 签发可控

由于是颁发 JWT token，如何保证风险可控呢？首先，我们这块针对 token 下发做了一个开关，随时能将下发新 token 功能下线；

其次，为了一点点推进颁发 JWT  token ，我们这块针对 mobile （userId）-> appId 进行灰度签发。

八 token 认证接口压测

由于是 JWT token，且认证服务压力挺大的，为了保证系统的稳定性，这块需要对认证 JWT token 接口进行压测。