一 面临问题

当前移动app最常见的保持登录的方案就是：持续刷新的JWT(json web token)方案。

即用户登录后，客户端获得JWT，此后不断刷新或是过期后刷新token。

这个方案使用得十分广泛，几乎成了事实标准。但并不安全，有以下几个问题：

1，JWT 密钥管理问题

JWT 的安全的基石是保证秘钥(secret key)的安全，因为一旦秘钥泄露，拥有秘钥的人可以伪造所有用户。这给管理带来了麻烦，我们还要完全信任管理人员，管理人员变动就要修改秘钥，而修改秘钥又会打断用户的登录状态。也许有人会说，这不是问题，这个和数据库账号密码管理一样啊，这个还有些不同，生产环境的数据库账号密码通常会有登录IP限制。

2，JWT 无法注销的问题

当用户修改密码后，通常需要注销之前颁发的token，为了实现这个功能需要引入token的集中储存和检查，这破坏了JWT分布式的优点。

3，JWT 的刷新机制有问题。

为了安全，很多人都知道token长期保持不变不安全，通常会采取刷新token的机制。当是当下，很多刷新机制是为了刷新而刷新，常见的token刷新机制是：到期后刷新，或是提前刷新，或者定时刷新。如果token被盗，黑客和合法用户都可以通过刷新来获取新的token，这并没带来实际的安全提升。

二 问题解答

1，针对JWT秘钥管理问题

这里给出的方案就是不使用JWT, 采用一个类似session 的机制，使用一个随机值(uuid)做token, 用户数据在后台集中的redis存储和查询。暂且称之为UUID Redis Token.

JWT的最大有点就是自身可存储用户数据，不用到集中的存储点查询，便于分布式应用，这个特点导致了已发布的JWT无法撤销。现实中，很多使用JWT的公司并不是单纯的在jwt里取用户数据，依旧在集中的服务器取数据。还有，对于像图片，视频等需要用户登录的检查，通常把token放到url 里，而JWT显得数据过大。

使用redis在后端保存用户信息有良好的扩展性，足够应满足大型网站的需求。

这个的uuid 并不要求按标准格式，只需不重复即可,对于PHP 很容易生成:

$token = bin2hex(random_bytes(20));

不要嫌这一行代码过于简单，对于地球上的公司，这已经足够安全了。

讲到这里，这个机制和传统的session 机制是类似的，uuid 相当于session-id，不同的地方是传统session客户端一定时间（通常为20分钟）不活跃就自动退出，我们需要做些改进，满足手机APP长期登陆的需求。

2，改进方案（UUID Redis Token）的特点

为了表述方便，以下假设手机APP要求90天内保持登陆，token超过2小时就刷新

• 每个token有一个较长的有效期，比如90天，这个是为了满足长期登录的需求;
• 每个token有一个较短的刷新间隔，比如2个小时。常常更换token 提升安全性;
• 每当token刷新时，创建并颁发新的token，同时修改旧的token的有效期，比如60秒后过期，保证旧的token快速到期同时又短暂可用，（并发请求时，可能会用到旧token）
• 每当用户重新登录或是修改密码，删除token。
• 刷新token时，利用redis或mysql 的锁机制，确保并发请求时只有个请求刷到新的token。
• 服务器token处理逻辑：通过token在redis里获取用户数据，如果找不到则表示token失效或错误，要求用户再次登录。如果找到用户信息且token 是2个小时内创建的，则不刷新token, 如果token创建时间超过2个小时前，则创建新的token给用户，服务器复制用户数据到新的token，同时修改旧token 60秒后过期。

此方案，多数情况下只是对redis的读写操作，性能极高，在刷新token时，需要用到redis或MySQL的锁机制防止并发刷新，确保同一客户端一次刷新只有一个请求刷到新的token，由于刷新token操作间隔的时间较长，不是高频操作，对性能也影响不大，配合redis集群，足够应对海量用户。