iOS Token保持

目前常见的机制:

一 使用传统的会话机制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就可以.

作者:黄洪清

链接:https://www.jianshu.com/p/b4cf771e570e

來源:简书

简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 157,012评论 4 359
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,589评论 1 290
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 106,819评论 0 237
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,652评论 0 202
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 51,954评论 3 285
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,381评论 1 210
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,687评论 2 310
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,404评论 0 194
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,082评论 1 238
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,355评论 2 241
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,880评论 1 255
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,249评论 2 250
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,864评论 3 232
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,007评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,760评论 0 192
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,394评论 2 269
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,281评论 2 259

推荐阅读更多精彩内容