一 面临问题
当前移动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把千万用户的安全寄希望于一个密钥的机制安全。