一种新的移动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屏幕同步软件 本文做者手工打造，热情推荐，网址: http://www.kwaicai.com

推荐阅读

• 一种全新的分布式用户认证架构设计
• 轻松理解Java的依赖注入和控制反转

本文系原创，转载需包含做者，出处和广告。