基於 token 的多平臺身份認證架構設計
轉自:哈莫
鏈接:cnblogs.com/beer/p/6029861.html
1、概述
在存在賬號體系的信息系統中,對身份的鑑定是非常重要的事情。
隨着移動互聯網時代到來,客戶端的類型越來越多, 逐漸出現了 一個服務器,N 個客戶端的格局 。
不同的客戶端產生了不同的用戶使用場景,這些場景:
-
有不同的環境安全威脅
-
不同的會話生存週期
-
不同的用戶權限控制體系
-
不同級別的接口調用方式
綜上所述,它們的身份認證方式也存在一定的區別。
本文將使用一定的篇幅對這些場景進行一些分析和梳理工作。
2、使用場景
下面是一些在 IT 服務常見的一些使用場景:
-
用戶在 web 瀏覽器端登錄系統, 使用系統服務
-
用戶在手機端(Android/iOS)登錄系統, 使用系統服務
-
用戶使用開放接口登錄系統, 調用系統服務
-
用戶在 PC 處理登錄狀態時通過手機掃碼授權手機登錄(使用得比較少)
-
用戶在手機處理登錄狀態進通過手機掃碼授權 PC 進行登錄(比較常見)
通過對場景的細分, 得到如下不同的認證 token 類別:
1、原始賬號密碼類別
-
用戶名和密碼
-
API 應用 ID/KEY
2、會話 ID 類別
-
瀏覽器端 token
-
移動端 token
-
API 應用 token
3、接口調用類別
-
接口訪問 token
-
身份授權類別
-
PC 和移動端相互授權的 token
3、token 的類別
不同場景的 token 進行如下幾個維度的對比:
天然屬性對比:
1、使用成本
本認證方式在使用的時候, 造成的不便性。比如:
-
賬號密碼需要用戶打開頁面然後逐個鍵入
-
二維碼需要用戶掏出手機進行掃碼操作
2、變化成本
本認證方式, token 發生變化時, 用戶需要做出的相應更改的成本:
-
用戶名和密碼發生變化時, 用戶需要額外記憶和重新鍵入新密碼
-
API 應用 ID/KEY 發生變化時, 第三方應用需要重新在代碼中修改並部署
-
授權二維碼發生變化時, 需要用戶重新打開手機應用進行掃碼
環境風險
-
被偷窺的風險
-
被抓包的風險
-
被僞造的風險
可調控屬性對比:
1、使用頻率
在網路中傳送的頻率
2、有效時間
此 token 從創建到終結的生存時間
最終的目標: 安全和影響。
安全和隱私性主要體現在:
-
token 不容易被竊取和盜用(通過對傳送頻率控制)
-
token 即使被竊取, 產生的影響也是可控的(通過對有效時間控制)
關於隱私及隱私破壞後的後果, 有如下的基本結論:
-
曝光頻率高的容易被截獲
-
生存週期長的在被截獲後產生的影響更嚴重和深遠
遵守如下原則:
-
變化成本高的 token 不要輕易變化
-
不輕易變化的 token 要減少曝光頻率(網絡傳輸次數)
-
曝光頻率高的 token 的生存週期要儘量短
將各類 token 的固有特點及可控屬性進行調控後, 對每個指標進行量化評分(1~5 分),我們可以得到如下的對比表:
備註: user_name/passwd 和 app_id/app_key 是等價的效果
4、token 的層級關係
參考上一節的對比表,可以很容易對這些不同用途的 token 進行分層,主要可以分爲 4 層:
-
密碼層:最傳統的用戶和系統之間約定的數字身份認證方式
-
會話層:用戶登錄後的會話生命週期的會話認證
-
調用層:用戶在會話期間對應用程序接口的調用認證
-
應用層:用戶獲取了接口訪問調用權限後的一些場景或者身份認證應用
token 的分層圖如下:
在一個多客戶端的信息系統裏面, 這些 token 的產生及應用的內在聯繫如下:
-
用戶輸入用戶名和用戶口令進行一次性認證
-
在 不同 的終端裏面生成擁有 不同 生命週期的會話 token
-
客戶端會話 token 從服務端交換生命週期短但曝光 頻繁 的接口訪問 token
-
會話 token 可以生成和刷新延長 access_token 的生存時間
-
access_token 可以生成生存週期最短的用於授權的二維碼的 token
使用如上的架構有如下的好處:
-
良好的統一性。可以解決不同平臺上認證 token 的生存週期的 歸一化 問題
-
良好的解耦性。核心接口調用服務器的認證 access_token 可以完成獨立的實現和部署
-
良好的層次性。不同平臺的可以有完全不同的用戶權限控制系統,這個控制可以在 會話層 中各平臺解決掉
4.1、賬號密碼
廣義的 賬號 / 密碼 有如下的呈現方式:
-
傳統的註冊用戶名和密碼
-
應用程序的 app_id/app_key
它們的特點如下:
1、會有特別的意義
比如:用戶自己爲了方便記憶,會設置有一定含義的賬號和密碼。
2、不常修改
賬號密碼對用戶有特別含義,一般沒有特殊情況不會願意修改。而 app_id/app_key 則會寫在應用程序中,修改會意味着重新發布上線的成本
3、一旦泄露影響深遠
正因爲不常修改,只要泄露了基本相當於用戶的網絡身份被泄露,而且只要沒被察覺這種身份盜用就會一直存在
所以在認證系統中應該儘量減少傳輸的機會,避免泄露。
4.2、客戶端會話 token
功能:
充當着 session 的角色,不同的客戶端有不同的生命週期。
使用步驟:
用戶使用賬號密碼,換取會話 token
不同的平臺的 token 有不同的特點:
Web 平臺生存週期短
主要原因:
-
環境安全性:由於 web 登錄環境一般很可能是公共環境,被他人盜取的風險值較大
-
輸入便捷性:在 PC 上使用鍵盤輸入會比較便捷
移動端生存週期長
主要原因:
-
環境安全性:移動端平臺是個人用戶極其私密的平臺,它人接觸的機會不大
-
輸入便捷性:在移動端上使用手指在小屏幕上觸摸輸入體驗差,輸入成本高
4.3、access_token
功能:
服務端應用程序 api 接口訪問和調用的憑證。
使用步驟:
使用具有較長生命週期的會話 token 來換取此接口訪問 token。
其曝光頻率直接和接口調用頻率有關,屬於高頻使用的憑證。爲了照顧到隱私性,儘量減少其生命週期,即使被截取了,也不至於產生嚴重的後果。
注意:在客戶端 token 之下還加上一個 access_token, 主要是爲了讓具有不同生命週期的客戶端 token 最後在調用 api 的時候, 能夠具有統一的認證方式。
4.4、pam_token
功能:
由已經登錄和認證的 PC 端生成的二維碼的原始串號(Pc Auth Mobile)。
主要步驟如下:
-
PC 上用戶已經完成認證,登錄了系統
-
PC 端生成一組和此用戶相關聯的 pam_token
-
PC 端將此 pam_token 的使用鏈接生成二維碼
-
移動端掃碼後,請求服務器,並和用戶信息關聯
-
移動端獲取 refresh_token(長時效的會話)
-
根據 refresh_token 獲取 access_token
-
完成正常的接口調用工作
備註:
生存週期爲 2 分鐘, 2 分鐘後過期刪除
沒有被使用時, 每 1 分鐘變一次
被使用後, 立刻刪除掉
此種認證模式一般不會被使用到
4.5、map_token
功能:
由已經登錄的移動 app 來掃碼認證 PC 端系統,並完成 PC 端系統的登錄(Mobile Auth Pc)。
主要步驟:
-
移動端完成用戶身份的認證登錄 app
-
未登錄的 PC 生成匿名的 map_token
-
移動端掃碼後在 db 中生成 map_token 和用戶關聯(完成簽名)
-
db 同時針對此用戶生成 web_token
-
PC 端一直以 map_token 爲參數查找此命名用戶的 web_token
-
PC 端根據 web_token 去獲取 access_token
-
後續正常的調用接口調用工作
備註:
生存週期爲 2 分鐘, 2 分鐘後過期刪除
沒有被使用時, 每 1 分鐘變一次
被使用後, 立刻刪除掉
5、小結與展望
本文所設計的基於 token 的身份認證系統,主要解決了如下的問題:
-
token 的分類問題
-
token 的隱私性參數設置問題
-
token 的使用場景問題
-
不同生命週期的 token 分層轉化關係
本文中提到的設計方法,在 應用層 中可以適用於且不限於如下場景中:
-
用戶登錄
-
有時效的優惠券發放
-
有時效的邀請碼發放
-
有時效的二維碼授權
-
具有時效 手機 / 郵件 驗證碼
-
多個不同平臺調用同一套 API 接口
-
多個平臺使用同一個身份認證中心
至於更多的使用場景,就需要大家去發掘了。
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/HzUwYQyvOJpIZue2OaBuzw