一種新的移動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的依賴注入和控制反轉

本文系原創，轉載需包含做者，出處和廣告。