移動APP和網頁登陸不同的一點就是,App不需要用戶每次使用都登陸,增加了易用性, 本文介紹一下App保持登陸的是實現機制。
移動APP的特點
移動APP和網頁登陸不同的一點就是,App不需要用戶每次使用都登陸,增加了易用性, 本文介紹一下App保持登陸的是實現機制
目前常見的機制:
一 使用傳統的會話機制session
把網頁的機制照搬過來,利用傳統網頁的記住登陸機制. 用戶輸入正確的用戶名和密碼后,創(chuàng)建登陸會話,同時生成一個記住登陸token保持在服務器端,同時發(fā)個客戶端. 客戶端每次啟動時,通過記錄登陸token新建會話,后續(xù)使用便采取session機制. 服務器端的可用Memcache 或 Redis 存儲會話.
回味一下這個機制,其中的記住登陸token,也可定個長的有效期,比如30天, 記住登陸token類似Oauth 2.0 的 Refresh token, Session機制里的Session Id 類似Access token. 只不過,Session機制里的Session Id 持續(xù)使用時,會自動延期.
這個機制的好處是充分利用現有知識,簡單易用,沒有太多新名詞概念不足之處是不便于分布式認證,還有Session機制對性能有一小點影響, 同時不符合Restful API無狀態(tài)的設計精神.
二 使用一個有效期很長的Token 機制
用戶正確登陸后,生成一個有效期很長的Token(比如半年),保存在服務器端,同時發(fā)給客戶端, 客戶端的每次請求就以這個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.
這個方案使用很廣泛,包括微信公眾平臺開發(fā) 也使用這個機制
但細細一想, 這個機制并不比方案二(使用一個長期的token)安全, 黑客如果能夠獲取Access Token,獲取Refresh Token也不難,采用兩個token 僅僅是給黑客增加點小麻煩.
一旦黑客獲取了獲取Refresh Token, 就可反復的刷新的Access Token
本文介紹一種新的機制
Token以舊換新的機制
這個機制只使用一個短期的Token,比如1天. 用戶登陸后, 這個Token發(fā)給客戶端, 用戶每次請求就使用這個Token認證身份, Token過期后憑此token換取新的Token,一個過期的Token只能換取一個新的Token,這是關鍵. 如果Token被盜, 黑客要持續(xù)使用也需持續(xù)的換取新的Token, 服務器一旦發(fā)現,一個舊Token多次試圖換取新Token,表示有異常. 這時強制用戶再次登陸. Token舊換新,不一定等過期了才換,應用啟動時就可舊換新,這個視具體情況而定.
這個Token的有效期,針對不同的應用可以調整. 以設計招商銀行的app為例:
-采用https 加密,確保傳輸安全.
-Token的有效期設為15分鐘,Token每15分鐘,以舊換新換取新的Token. 正常情況下,這個以舊換新對用戶不可見,一但兩人試圖以舊換新,兩人都阻止,需要再次登陸.
-對于修改密碼和轉賬支付這樣的關鍵操作,要求用戶輸入密碼. 這樣就萬無一失了.
重復一下,設計安全機制時,一定要使用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通常發(fā)行了就不能注銷,只能等其自行過期失效. 這時為了保證安全性,使用短期JWT,再加上述的token以舊換新,就很有效.
本文所說的Token舊換新機制,對上述兩種token均適用. Token 就是一個字符串信息,就算復制一萬份,彼此也毫無差別, 有了以舊換新的機制,Token就有點像實物了, 已經換過了自然不能再換,不管有多少份,只能有一個換取新的Token 當兩個人先后拿著同一個token 來換新,我們不能判斷到底哪個合法,哪個非法,好吧,兩人都再次登陸確認身份吧.
更新
對于普通的應用,有效期設為24小時,每次啟動應用時換一下token就可以,不用太復雜
對于網銀這樣的應用, 啟動時換一下, 再加上用個定時器(timer),每15分鐘換一下token就可以.
