一種新的移動APP保持登陸的實現(xiàn)機制介紹
移動APP的特點
移動APP和網(wǎng)頁登陸不同的一點就是,App不需要用戶每次使用都登陸,增加了易用性, 本文介紹一下App保持登陸的是實現(xiàn)機制
目前常見的機制:
一 使用傳統(tǒng)的會話機制session
把網(wǎng)頁的機制照搬過來,利用傳統(tǒng)網(wǎng)頁的記住登陸機制. 用戶輸入正確的用戶名和密碼后,創(chuàng)建登陸會話,同時生成一個記住登陸token保持在服務(wù)器端,同時發(fā)個客戶端. 客戶端每次啟動時,通過記錄登陸token新建會話,后續(xù)使用便采取session機制. 服務(wù)器端的可用Memcache 或 Redis 存儲會話.
回味一下這個機制,其中的記住登陸token,也可定個長的有效期,比如30天, 記住登陸token類似Oauth 2.0 的 Refresh token, Session機制里的Session Id 類似Access token. 只不過,Session機制里的Session Id 持續(xù)使用時,會自動延期.
這個機制的好處是充分利用現(xiàn)有知識,簡單易用,沒有太多新名詞概念不足之處是不便于分布式認(rèn)證,還有Session機制對性能有一小點影響, 同時不符合Restful API無狀態(tài)的設(shè)計精神.
二 使用一個有效期很長的Token 機制
用戶正確登陸后,生成一個有效期很長的Token(比如半年),保存在服務(wù)器端,同時發(fā)給客戶端, 客戶端的每次請求就以這個Token驗證身份. 采用https 傳輸加密, Token中途不會被獲取, 而保存在本地的Token其他程序也訪問不了. 對應(yīng)普通應(yīng)用而言,這個方案也是可以的.
三 使用一個長期的Refresh Token 和 短期的Access Token.
對于方案二, 如果手機硬件本身被黑客獲取過, 長期Token可能被盜,有潛在的風(fēng)險. 考慮到這一點, Oauth 2.0 標(biāo)準(zhǔn)推薦采用Refresh Token和Access Token. Refresh Token 有效期很長, Access Token 有效期很短. 用戶登陸后,同時獲得Refresh Token 和 Access Token,平時就用 Access Token, Access Token 過期后就用Refresh Token 獲取新的Access Token.
這個方案使用很廣泛,包括微信公眾平臺開發(fā) 也使用這個機制
但細(xì)細(xì)一想, 這個機制并不比方案二(使用一個長期的token)安全, 黑客如果能夠獲取Access Token,獲取Refresh Token也不難,采用兩個token 僅僅是給黑客增加點小麻煩.
一旦黑客獲取了獲取Refresh Token, 就可反復(fù)的刷新的Access Token
本文介紹一種新的機制
Token以舊換新的機制
這個機制只使用一個短期的Token,比如1天. 用戶登陸后, 這個Token發(fā)給客戶端, 用戶每次請求就使用這個Token認(rèn)證身份, Token過期后憑此token換取新的Token,一個過期的Token只能換取一個新的Token,這是關(guān)鍵. 如果Token被盜, 黑客要持續(xù)使用也需持續(xù)的換取新的Token, 服務(wù)器一旦發(fā)現(xiàn),一個舊Token多次試圖換取新Token,表示有異常. 這時強制用戶再次登陸. Token舊換新,不一定等過期了才換,應(yīng)用啟動時就可舊換新,這個視具體情況而定.
這個Token的有效期,針對不同的應(yīng)用可以調(diào)整. 以設(shè)計招商銀行的app為例:
- 采用https 加密,確保傳輸安全.
- Token的有效期設(shè)為15分鐘,Token每15分鐘,以舊換新?lián)Q取新的Token. 正常情況下,這個以舊換新對用戶不可見,一但兩人試圖以舊換新,兩人都阻止,需要再次登陸.
- 對于修改密碼和轉(zhuǎn)賬支付這樣的關(guān)鍵操作,要求用戶輸入密碼. 這樣就萬無一失了.
重復(fù)一下,設(shè)計安全機制時,一定要使用https, 沒有https, 多數(shù)安全設(shè)計都是無用功
附: Token 簡介
Token 中文的翻譯就是令牌, 識別身份的依據(jù). 通常token有兩種:
一 不含內(nèi)容的token
這種token這是一個唯一的hash值, 要知道這個token是誰,要到一個中心服務(wù)器查詢. 在中心服務(wù)器,用戶數(shù)據(jù)可能儲存于文件或是數(shù)據(jù)庫或是Redis等. 在session 機制的Cookie里 有一個session id, 本質(zhì)上也是一個這類token.
二 包含內(nèi)容的token
這種token, 就像一個身份證,包含公開的用戶信息, 通過簽名機制確保token無法偽造. 最常見的這類token 就是: Json web token (JWT) 這種token好處是不用到中心服務(wù)器查詢,對于分布式系統(tǒng)很有用, 比如用戶登陸后,要看視頻,要下載文件. 而視頻,文件資源都需驗證用戶身份,視頻,文件資源在不同的服務(wù)器,甚至由不同的公司提供,這時可分布式驗證的JWT就很有用. 這種可分布式驗證的Token通常發(fā)行了就不能注銷,只能等其自行過期失效. 這時為了保證安全性,使用短期JWT,再加上述的token以舊換新,就很有效.
本文所說的Token舊換新機制,對上述兩種token均適用. Token 就是一個字符串信息,就算復(fù)制一萬份,彼此也毫無差別, 有了以舊換新的機制,Token就有點像實物了, 已經(jīng)換過了自然不能再換,不管有多少份,只能有一個換取新的Token 當(dāng)兩個人先后拿著同一個token 來換新,我們不能判斷到底哪個合法,哪個非法,好吧,兩人都再次登陸確認(rèn)身份吧.
更新
- 對于普通的應(yīng)用,有效期設(shè)為24小時,每次啟動應(yīng)用時換一下token就可以,不用太復(fù)雜
- 對于網(wǎng)銀這樣的應(yīng)用, 啟動時換一下, 再加上用個定時器(timer),每15分鐘換一下token就可以.