2023年7月4日发(作者：)

⼀种新的移动APP保持登陆的实现机制介绍2019-8-8更新，考虑到JWT的安全依赖秘钥的安全，实际管理中，秘钥难于管理，这⾥提供⼀个改进⽅案移动⽹页APP保持⽤户登录的改进⽅案(UUID Redis Token)移动APP的特点移动APP和⽹页登陆不同的⼀点就是,App不需要⽤户每次使⽤都登陆,增加了易⽤性, 本⽂介绍⼀下App保持登陆的是实现机制⽬前常见的机制:⼀ 使⽤传统的会话机制session把⽹页的机制照搬过来,利⽤传统⽹页的记住登陆机制.⽤户输⼊正确的⽤户名和密码后,创建登陆会话,同时⽣成⼀个记住登陆token保持在服务器端,同时发个客户端.客户端每次启动时,通过记录登陆token新建会话,后续使⽤便采取session机制.服务器端的可⽤Memcache 或 Redis 存储会话.回味⼀下这个机制,其中的记住登陆token,也可定个长的有效期,⽐如30天,记住登陆token类似Oauth 2.0 的 Refresh token, Session机制⾥的Session Id 类似Access token.只不过,Session机制⾥的Session Id 持续使⽤时,会⾃动延期.这个机制的好处是充分利⽤现有知识,简单易⽤,没有太多新名词概念不⾜之处是不便于分布式认证,还有Session机制对性能有⼀⼩点影响, 同时不符合Restful API⽆状态的设计精神.⼆ 使⽤⼀个有效期很长的Token 机制⽤户正确登陆后,⽣成⼀个有效期很长的Token(⽐如半年),保存在服务器端,同时发给客户端, 客户端的每次请求就以这个Token验证⾝份.采⽤https 传输加密, Token中途不会被获取, ⽽保存在本地的Token其他程序也访问不了.对应普通应⽤⽽⾔,这个⽅案也是可以的.三 使⽤⼀个长期的Refresh Token 和 短期的Access Token.对于⽅案⼆, 如果⼿机硬件本⾝被⿊客获取过, 长期Token可能被盗,有潜在的风险.考虑到这⼀点, Oauth 2.0 标准推荐采⽤Refresh Token和Access h Token 有效期很长, Access Token 有效期很短.⽤户登陆后,同时获得Refresh Token 和 Access Token,平时就⽤ Access Token, Access Token 过期后就⽤Refresh Token 获取新的Access Token.这个⽅案使⽤很⼴泛,包括微信公众平台开发 也使⽤这个机制但细细⼀想, 这个机制并不⽐⽅案⼆(使⽤⼀个长期的token)安全,⿊客如果能够获取Access Token,获取Refresh Token也不难,采⽤两个token 仅仅是给⿊客增加点⼩⿇烦.⼀旦⿊客获取了获取Refresh Token, 就可反复的刷新的Access Token本⽂介绍⼀种新的机制Token以旧换新的机制这个机制只使⽤⼀个短期的Token,⽐如1天.⽤户登陆后, 这个Token发给客户端, ⽤户每次请求就使⽤这个Token认证⾝份, Token过期后凭此token换取新的Token,⼀个过期的Token只能换取⼀个新的Token,这是关键. 如果Token被盗, ⿊客要持续使⽤也需持续的换取新的Token, 服务器⼀旦发现,⼀个旧Token多次试图换取新Token,表⽰有异常. 这时强制⽤户再次登陆.Token旧换新,不⼀定等过期了才换,应⽤启动时就可旧换新,这个视具体情况⽽定.这个Token的有效期,针对不同的应⽤可以调整.以设计招商银⾏的app为例:1, 采⽤https 加密,确保传输安全.2,Token的有效期设为15分钟,Token每15分钟,以旧换新换取新的Token. 正常情况下,这个以旧换新对⽤户不可见,⼀但两⼈试图以旧换新,两⼈都阻⽌,需要再次登陆.3,对于修改密码和转账⽀付这样的关键操作,要求⽤户输⼊密码.这样就万⽆⼀失了.重复⼀下,设计安全机制时,⼀定要使⽤https, 没有https, 多数安全设计都是⽆⽤功附: Token 简介Token 中⽂的翻译就是令牌, 识别⾝份的依据.通常token有两种:⼀ 不含内容的token这种token这是⼀个唯⼀的hash值, 要知道这个token是谁,要到⼀个中⼼服务器查询.在中⼼服务器,⽤户数据可能储存于⽂件或是数据库或是Redis等.在session 机制的Cookie⾥ 有⼀个session id, 本质上也是⼀个这类token.⼆ 包含内容的token这种token, 就像⼀个⾝份证,包含公开的⽤户信息, 通过签名机制确保token⽆法伪造.最常见的这类token 就是: Json web token (JWT)这种token好处是不⽤到中⼼服务器查询,对于分布式系统很有⽤, ⽐如⽤户登陆后,要看视频,要下载⽂件.⽽视频,⽂件资源都需验证⽤户⾝份,视频,⽂件资源在不同的服务器,甚⾄由不同的公司提供,这时可分布式验证的JWT就很有⽤.这种可分布式验证的Token通常发⾏了就不能注销,只能等其⾃⾏过期失效.这时为了保证安全性,使⽤短期JWT,再加上述的token以旧换新,就很有效.本⽂所说的Token旧换新机制,对上述两种token均适⽤.Token 就是⼀个字符串信息,就算复制⼀万份,彼此也毫⽆差别,有了以旧换新的机制,Token就有点像实物了, 已经换过了⾃然不能再换,不管有多少份,只能有⼀个换取新的Token当两个⼈先后拿着同⼀个token 来换新,我们不能判断到底哪个合法,哪个⾮法,好吧,两⼈都再次登陆确认⾝份吧.更新对于普通的应⽤,有效期设为24⼩时,每次启动应⽤时换⼀下token就可以,不⽤太复杂对于⽹银这样的应⽤, 启动时换⼀下, 再加上⽤个定时器(timer),每15分钟换⼀下token就可以.推荐阅读⼀种全新的分布式⽤户认证架构设计轻松理解Java的依赖注⼊和控制反转本⽂系原创，转载需包含作者，出处和⼴告。