返回

商务服务

轻松筹1.6亿注册用户的Passport账户系统架构

2024-10-31 17:30

轻松筹是全国1.6亿人使用的全民众筹平台，几乎所有核心业务都依赖于账号系统，账号系统的用户体验，安全性，稳定性直接影响着轻松筹所有业务的运行；
轻松筹的发展非常迅速，已经展开了多条产品线，单点登录的需求愈加强烈；另外由于历史包袱的原因，也遗留了一些问题亟待解决。
本次交流主要与大家分享一下轻松筹账号系统(侧重登录授权服务)的架构设计和改造方案。

由于历史包袱的遗留问题，轻松筹的账号系统（登录授权服务）之前主要存在以下几个方面的不足：

1. 由于历史包袱的遗留问题，三端登录方式不统一
2. 产品线增多，单点登录的需求越来越强烈
3. 安全性不够
4. 容灾能力不够

需要达到以下几个方面的目标

1. 保证只要用户较长时间段（比如30天)内登录过，就不需要重新登录
2. 单点登录，在一个站点登录后，另外一个站点就不需要重复登录(用户几乎无感知)
3. 采用第三方登录的时候，能使用每一个站点对应的公众号

1. token难以伪造，具有一定不可逆性
2. token应该有较快的过期机制，避免被人获取token后伪造用户操作
3. 被恶意窃取后，具有发现机制

1. token具有自解释性，即自带某些信息，在某些极端恶劣情况下(比如存储服务挂了)，依然能提供服务

概述

账号系统最核心的功能就是登录授权，总体思路也很简单：

用户登录成功后，服务端会生成token信息，并将其和用户信息关联起来，返回给前端token信息，

前端携带token来访问所有接口，后端再根据前端发过来的token信息标识这是哪个用户的行为

这里所说的token信息包括以下几个字段（服务端生成后返回给前端的）

access_token用户的唯一标识需要验证登录的每一个请求都需要携带，放在http请求头Qsc-Token中默认过期时间2小时token_typetoken的类型暂时保留无用

access_token的过期时间

前端发起请求的时候可以先用这个时间预先判断一下，减少不必要的请求 refresh_token刷新token当access_token过期时，用refresh_token去换取新的token信息默认过期时间30天

服务端token存储的信息(服务端记录的信息)

auth_type

服务端存储的数据(key-val存储):

key(access_token) =(user_id,session_id,platform,auth_type)

key(refresh_token) =(user_id,session_id,platform,auth_type)

key(user_id,platform) =(access_token,refresh_token,expires_in,token_type)

说明：

1. access_token=hex(hash(uid+time)+aes(uid+time))得到，达到目标B1
2. access_token过期时间较短，refresh_token较长，两者结合，达到目标A1，B2
3. token中自带uid信息，即使服务存储挂了，依然不影响其它业务，达到目标C1
4. 前端h5（"wxh5" "pch5" "waph5"）每一个平台仅维护一个token，多次登录会剔除旧的，实现目标B3
5. passport前端拿到这个token信息之后，应该记录一下获取时间cur_time；通过 cur_time+expires_in与当前时间 提前进行比较来判断token是否已经过期,减少不必要的后端请求
6. 需要登录的接口，前端需要每次都在请求头中写入Qsc-Token:access_token 字段

当access_token过期时，用refresh_token去换取新的token信息，刷新token接口流程为：

1. 用户使用refresh_token调用刷新token接口，后端判断，若key(refresh_token)不存在，直接报错，
2. 若是存在，再用key(user_id,platform) 存储的信息校验两者当前的refresh_token是否一致，若是不一致，说明有人利用这个token在你之前调用了刷新token接口
3. 若是一致，则重新生成token信息，替换 key(user_id,platform) 存储的信息，并且处理旧的信息：旧的key(access_token)直接删掉，旧的key(refresh_token)保留一段时间

注意：

1. 前端刷新token的时候，应该保证操作是互斥(串行)的，否则影响第上述的“踢人”功能，（app的前端互斥很好做，加锁就可以了；h5怎么实现前端互斥，后面会介绍）
2. 后端刷新token的时候，应该保证操作是互斥(串行)的(分布式锁)，保证始终只有一个token有效

关于踢人逻辑的说明：

需要在以下两种情况都能达到踢人的效果：

1. 用户的账号被窃取(第三方账号，或者手机验证码)
2. 用户前端的refresh_token被窃取

解决方法:

1. 以上两种情况用户操作后，都会重新生成token信息，并且替换key(user_id,platform) 存储的信息，然后将旧的key(access_token)直接删掉，旧的key(refresh_token)保留一段时间，这个时候这个恶意用户是可以伪装的
2. 但是当原来的用户调用刷新token接口的时候(使用的是旧的refresh_token)，这个时候还是能获得key(refresh_token)里面的信息，再取出key(user_id,platform) 存储的信息来校验，会发现两处的refresh_token是不一致的，既可以发现是被人踢下去的

特别说明：

为什么不用一个token随着请求反复刷新来达到 access_token和refresh_token的效果呢？？

1. 因为这种方式前端页面会有并发请求的情况，token的刷新是需要加锁的，会带来很大的开销；
2. 没法保证前端 刷新token 的互斥，会导致反复失效的情况

对于所有产品线的web平台都实现单点登录SSO(Single Sign On)的功能，这样只要在一个产品线上(比如站点A)登录了，在其它产品线上(比如站点B)就不需要再重新登陆了

实现目标A2，A3