一面临问题

当前移动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集群，足够应对海量用户。

三更进一步的安全措施

对于对安全有极致要求的公司，这里还有进一步的安全措施。

1,对用户token做哈希运算

对UUID，也就是用户的token，作一次SHA256哈希运算，以此哈希值作为后台redis的key值，这样就算是服务器的超级管理员，也无法查看用户的token，有的同学可能担心做一次格外的哈希运算是否会加大服务器的负荷，这样的多担心是多余，一次SHA256哈希运算对服务器来说微乎其微，可以忽略不计。

如果觉得这还不安全，我们还可以以UUID为密钥，对会话数据，也就是redis的value值做AES加密（AES算法的格外负荷极低），这样就彻底安全了，就算是公司老板，超级管理员也看不到。

2,用户token被盗检查

增加token防盗检查。如果Token被黑客获取，根据我们的设计，黑客和合法用户都需每两个小时来刷新一次，我们可以识别这样的异常，提升安全性。

这里以身份证换证类比讲述，身份证的以旧换新，一个旧证只能换一个新证，我们可以对已经换过的旧证集中登记，如果发现一个证件两次来换新证，就视为异常。

同理，用户token的刷新操作，可以看作一次以旧换新，一个旧token只能换一个新的token，我们在服务器集中记录最近换过的旧token，如果发现同一token，试图两次来换新的token，则视为异常，注销该用户，要求用户用密码再次登录。以上这些逻辑只需要在刷新token的时候处理，所以对服务器的格外负荷不大。

如果大家觉得以上处理机制过于复杂。

对于很多中小企业，安全要求不高，直接用session机制，会话时长直接设为90天，加上https防监听，就够了，这个也比JWT把千万用户的安全寄希望于一个密钥的机制安全。