一种新的移动APP保持登陆的实现机制介绍
一种新的移动APP保持登陆的实现机制介绍
黄洪清 发表于4个月前
一种新的移动APP保持登陆的实现机制介绍
  • 发表于 4个月前
  • 阅读 987
  • 收藏 98
  • 点赞 1
  • 评论 19

腾讯云 十分钟定制你的第一个小程序>>>   

摘要: 新的移动APP保持登陆的安全机制

##移动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 Token. Refresh 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就可以.
标签: android ios api
共有 人打赏支持
粉丝 3
博文 3
码字总数 3944
评论 (19)
zzuqiang
以旧换新的时机如何把控?客户端自己处理快要过期的token然后去以旧换新?
ming133
谢谢博主分享,请问更换token的规则是什么,客户app退出了如何更换?
翠翠

引用来自“zzuqiang”的评论

以旧换新的时机如何把控?客户端自己处理快要过期的token然后去以旧换新?
作者的意思应该是过期时间只是作为“这个 Token 必须要更换了”的依据,而不是“这个 Token 无效了”的依据。

只要没被换过,这个老的 Token 任何时候都可以拿来换一个新的 Token,但是一个老的 Token 不能两次调用更换新 Token 的接口,而且一旦这种情况出现,不管是新的还是旧的 Token 全部作废,强制使用者重新登录,重新获取 Token。
黄洪清

引用来自“zzuqiang”的评论

以旧换新的时机如何把控?客户端自己处理快要过期的token然后去以旧换新?
对应JWT,客户端可自己判断token是否过期.
不要等过期了才换,提前换取.未雨绸缪.
可以在应用启动时换取.
黄洪清

引用来自“ming133”的评论

谢谢博主分享,请问更换token的规则是什么,客户app退出了如何更换?
应用启动时换取, 不要等过期了才换,提前换取.
黄洪清

引用来自“zzuqiang”的评论

以旧换新的时机如何把控?客户端自己处理快要过期的token然后去以旧换新?

引用来自“翠翠”的评论

作者的意思应该是过期时间只是作为“这个 Token 必须要更换了”的依据,而不是“这个 Token 无效了”的依据。

只要没被换过,这个老的 Token 任何时候都可以拿来换一个新的 Token,但是一个老的 Token 不能两次调用更换新 Token 的接口,而且一旦这种情况出现,不管是新的还是旧的 Token 全部作废,强制使用者重新登录,重新获取 Token。
对于JWT, token 本身有个过期时间,过期了可以换新.
通常要提前换取,或是有个宽限期. 要避免并发情况下,自己多次换取.
翠翠

引用来自“zzuqiang”的评论

以旧换新的时机如何把控?客户端自己处理快要过期的token然后去以旧换新?

引用来自“翠翠”的评论

作者的意思应该是过期时间只是作为“这个 Token 必须要更换了”的依据,而不是“这个 Token 无效了”的依据。

只要没被换过,这个老的 Token 任何时候都可以拿来换一个新的 Token,但是一个老的 Token 不能两次调用更换新 Token 的接口,而且一旦这种情况出现,不管是新的还是旧的 Token 全部作废,强制使用者重新登录,重新获取 Token。

引用来自“huanghq”的评论

对于JWT, token 本身有个过期时间,过期了可以换新.
通常要提前换取,或是有个宽限期. 要避免并发情况下,自己多次换取.
那你这个过期时间太短了,客户如果隔了一天没登录,基本就肯定要重新登录了,使用 refresh token 的话,一般可以设置 30 天的有效期呢。
黄洪清

引用来自“zzuqiang”的评论

以旧换新的时机如何把控?客户端自己处理快要过期的token然后去以旧换新?

引用来自“翠翠”的评论

作者的意思应该是过期时间只是作为“这个 Token 必须要更换了”的依据,而不是“这个 Token 无效了”的依据。

只要没被换过,这个老的 Token 任何时候都可以拿来换一个新的 Token,但是一个老的 Token 不能两次调用更换新 Token 的接口,而且一旦这种情况出现,不管是新的还是旧的 Token 全部作废,强制使用者重新登录,重新获取 Token。

引用来自“huanghq”的评论

对于JWT, token 本身有个过期时间,过期了可以换新.
通常要提前换取,或是有个宽限期. 要避免并发情况下,自己多次换取.

引用来自“翠翠”的评论

那你这个过期时间太短了,客户如果隔了一天没登录,基本就肯定要重新登录了,使用 refresh token 的话,一般可以设置 30 天的有效期呢。
隔了一天没使用, 就重新使用时再换取啊.
翠翠

引用来自“zzuqiang”的评论

以旧换新的时机如何把控?客户端自己处理快要过期的token然后去以旧换新?

引用来自“翠翠”的评论

作者的意思应该是过期时间只是作为“这个 Token 必须要更换了”的依据,而不是“这个 Token 无效了”的依据。

只要没被换过,这个老的 Token 任何时候都可以拿来换一个新的 Token,但是一个老的 Token 不能两次调用更换新 Token 的接口,而且一旦这种情况出现,不管是新的还是旧的 Token 全部作废,强制使用者重新登录,重新获取 Token。

引用来自“huanghq”的评论

对于JWT, token 本身有个过期时间,过期了可以换新.
通常要提前换取,或是有个宽限期. 要避免并发情况下,自己多次换取.

引用来自“翠翠”的评论

那你这个过期时间太短了,客户如果隔了一天没登录,基本就肯定要重新登录了,使用 refresh token 的话,一般可以设置 30 天的有效期呢。

引用来自“huanghq”的评论

隔了一天没使用, 就重新使用时再换取啊.
那我没理解错,“过期时间只是作为“这个 Token 必须要更换了”的依据,而不是“这个 Token 无效了”的依据。”
悟饭_east
好文章,mark
silverYi
这个跟微信里面的发消息接口一样,时间到候保留老的token有效,用老的换取新的继续使用
shore
旧换新也不会持续使用旧的token 感觉效果等同refresh设置的短一些
无即是有
确实比oauth2先进一些
黄洪清

引用来自“shore”的评论

旧换新也不会持续使用旧的token 感觉效果等同refresh设置的短一些
在Oauth2.0 里 refresh token 设置长时间,就是为了减少使用频率,提高安全性.
如果refresh token设置的短一些, refresh token 就没有必要了.
黄洪清

引用来自“silverYi”的评论

这个跟微信里面的发消息接口一样,时间到候保留老的token有效,用老的换取新的继续使用
通常由于时钟差,多数到期的token会有一个宽限期,新旧同时有效.
还记得,换二代身份证吧, 有段时间一代身份证也可以用.
这个旧换新,还有个功能就是发现和阻止异常.
strfreedom
请问如何界定“一个旧Token多次试图换取新Token,表示有异常”这个异常的举动
黄洪清

引用来自“strfreedom”的评论

请问如何界定“一个旧Token多次试图换取新Token,表示有异常”这个异常的举动
这个服务器端用表记录一下,就可以判断.
wildq2018
以旧换新其实就是抛弃了refreshtoken,让accesstoken自动更新啊,也只是给黑客造成一点点麻烦而已吧
黄洪清

引用来自“wildq2018”的评论

以旧换新其实就是抛弃了refreshtoken,让accesstoken自动更新啊,也只是给黑客造成一点点麻烦而已吧
不是,会把黑客挡在门外.
×
黄洪清
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: