用户登录使用jwt实现token认证，用户模块分离为一个系统。假如有三个子业务系统，分别登录了，怎么控制每个子系统的注销？

Question

用户登录使用jwt实现token认证，用户模块分离为一个系统。我有三个子业务系统，分别登录了，怎么控制每个子系统的注销？

Answer 1

老生常谈了,简单来说,采用jwt的情景,应该是无状态的,所谓无状态,就是服务端不保存任何状态信息,让一个token失效也就无从谈起了,这种情景就应该是客户端删掉token就完事儿了.
当然了,计划赶不上变化,出现了这种需求,我们就只能在服务端保存token的状态了,通常是保存禁用信息,比如token A 在甲系统注销登录,在缓存中维护一个key,内容就是"tokenA已经在甲系统注销",过期时间与token本身的过期时间相同,操作时先检查缓存.
不过这样系统的复杂度提高很多.

Answer 2

最简单的实现方式就是 jwt 在加密时就应该有来源字段 用户模块通过不同的来源生成不同的jwtToken 这样每个子业务注销都不会有影响

Answer 3

1）思考一下，为什么用 jwt 实现 token，而不是其他的 token 类型？

使用 jwt 做为 token，那么在验证 token 的过程中，不需要和用户模块交互，降低了用户模块的访问压力。但是 jwt 的缺点也很明显，无法revoke token，所以一般会将 token 超时的时间设置的比较短。

2）是否需要 revoke token？

如果需要通过 revoke token 的方式来注销用户，那么 jwt 不是个好的选择。一般选择使用 jwt 作为 token 的话，一般都不会有 revoke token 的需求。因为jwt token 的属性不是保存在用户模块的后台，而是打包到了 token 本身，一旦 token 被签发出去，就无法修改了。

3）如何实现注销，部分注销

基于 token 的系统设计，注销的流程一般是 revoke token，当然，如果只从部分业务模块注销，也可以在用户模块中，对 token 进行标记处理。比如在用户模块中，修改 token 的 scope 属性。

4）认证还是授权？
认证：告诉我你是谁？401
授权：我知道你是谁，但是你是否有权做请求的事情？403

如果采用修改 token 的 scope 来实现部分模块的注销，实际上是取消了用户授权（403），但是 token 本身仍然是有效的，通过 token，仍然能够完成认证。