點擊上方 java項目開發，選擇 設爲星標
html
優質項目，及時送達
前端
-----vue
一、概述
在存在帳號體系的信息系統中，對身份的鑑定是很是重要的事情。java
隨着移動互聯網時代到來，客戶端的類型愈來愈多， 逐漸出現了 一個服務器，N 個客戶端的格局 。react
不一樣的客戶端產生了不一樣的用戶使用場景，這些場景：web
有不一樣的環境安全威脅spring
不一樣的會話生存週期數據庫
不一樣的用戶權限控制體系後端
不一樣級別的接口調用方式api
綜上所述，它們的身份認證方式也存在必定的區別。
本文將使用必定的篇幅對這些場景進行一些分析和梳理工做。
二、使用場景
下面是一些在 IT 服務常見的一些使用場景:
用戶在 web 瀏覽器端登陸系統, 使用系統服務
用戶在手機端（Android/iOS）登陸系統, 使用系統服務
用戶使用開放接口登陸系統, 調用系統服務
用戶在 PC 處理登陸狀態時經過手機掃碼受權手機登陸（使用得比較少）
用戶在手機處理登陸狀態進經過手機掃碼受權 PC 進行登陸（比較常見）
經過對場景的細分, 獲得以下不一樣的認證 token 類別：
一、原始帳號密碼類別
用戶名和密碼
API 應用 ID/KEY
二、會話 ID 類別
瀏覽器端 token
移動端 token
API 應用 token
三、接口調用類別
接口訪問 token
身份受權類別
PC 和移動端相互受權的 token
三、token 的類別
不一樣場景的 token 進行以下幾個維度的對比:
自然屬性對比:
一、使用成本
本認證方式在使用的時候, 形成的不便性。好比:
帳號密碼須要用戶打開頁面而後逐個鍵入
二維碼須要用戶掏出手機進行掃碼操做
二、變化成本
本認證方式, token 發生變化時, 用戶須要作出的相應更改的成本:
用戶名和密碼發生變化時, 用戶須要額外記憶和從新鍵入新密碼
API 應用 ID/KEY 發生變化時, 第三方應用須要從新在代碼中修改並部署
受權二維碼發生變化時, 須要用戶從新打開手機應用進行掃碼
環境風險
被偷窺的風險
被抓包的風險
被僞造的風險
可調控屬性對比:
一、使用頻率
在網路中傳送的頻率
二、有效時間
此 token 從建立到終結的生存時間
最終的目標: 安全和影響。
安全和隱私性主要體如今:
token 不容易被竊取和盜用（經過對傳送頻率控制）
token 即便被竊取, 產生的影響也是可控的（經過對有效時間控制）
關於隱私及隱私破壞後的後果, 有以下的基本結論:
曝光頻率高的容易被截獲
生存週期長的在被截獲後產生的影響更嚴重和深遠
遵照以下原則:
變化成本高的 token 不要輕易變化
不輕易變化的 token 要減小曝光頻率（網絡傳輸次數）
曝光頻率高的 token 的生存週期要儘可能短
將各種 token 的固有特色及可控屬性進行調控後, 對每一個指標進行量化評分（1~5 分），咱們能夠獲得以下的對比表：
備註: username/passwd 和 appid/app_key 是等價的效果
四、token 的層級關係
參考上一節的對比表，能夠很容易對這些不一樣用途的 token 進行分層，主要能夠分爲 4 層：
密碼層：最傳統的用戶和系統之間約定的數字身份認證方式
會話層：用戶登陸後的會話生命週期的會話認證
調用層：用戶在會話期間對應用程序接口的調用認證
應用層：用戶獲取了接口訪問調用權限後的一些場景或者身份認證應用
token 的分層圖以下：
在一個多客戶端的信息系統裏面, 這些 token 的產生及應用的內在聯繫以下:
用戶輸入用戶名和用戶口令進行一次性認證
在 不一樣 的終端裏面生成擁有 不一樣 生命週期的會話 token
客戶端會話 token 從服務端交換生命週期短但曝光 頻繁 的接口訪問 token
會話 token 能夠生成和刷新延長 access_token 的生存時間
access_token 能夠生成生存週期最短的用於受權的二維碼的 token
使用如上的架構有以下的好處：
良好的統一性。能夠解決不一樣平臺上認證 token 的生存週期的 歸一化 問題
良好的解耦性。核心接口調用服務器的認證 access_token 能夠完成獨立的實現和部署
良好的層次性。不一樣平臺的能夠有徹底不一樣的用戶權限控制系統，這個控制能夠在 會話層 中各平臺解決掉
4.一、帳號密碼
廣義的 帳號 / 密碼 有以下的呈現方式:
傳統的註冊用戶名和密碼
應用程序的 appid/appkey
它們的特色以下：
一、會有特別的意義
好比：用戶本身爲了方便記憶，會設置有必定含義的帳號和密碼。
二、不常修改
帳號密碼對用戶有特別含義，通常沒有特殊狀況不會願意修改。而 appid/appkey 則會寫在應用程序中，修改會意味着從新發布上線的成本
三、一旦泄露影響深遠
正由於不常修改，只要泄露了基本至關於用戶的網絡身份被泄露，並且只要沒被察覺這種身份盜用就會一直存在
因此在認證系統中應該儘可能減小傳輸的機會，避免泄露。
4.二、客戶端會話 token
功能：
充當着 session 的角色，不一樣的客戶端有不一樣的生命週期。
使用步驟：
用戶使用帳號密碼，換取會話 token
不一樣的平臺的 token 有不一樣的特色：
Web 平臺生存週期短
主要緣由：
環境安全性：因爲 web 登陸環境通常極可能是公共環境，被他人盜取的風險值較大
輸入便捷性：在 PC 上使用鍵盤輸入會比較便捷
移動端生存週期長
主要緣由：
環境安全性：移動端平臺是我的用戶極其私密的平臺，它人接觸的機會不大
輸入便捷性：在移動端上使用手指在小屏幕上觸摸輸入體驗差，輸入成本高
4.三、access_token
功能：
服務端應用程序 api 接口訪問和調用的憑證。
使用步驟：
使用具備較長生命週期的會話 token 來換取此接口訪問 token。
其曝光頻率直接和接口調用頻率有關，屬於高頻使用的憑證。爲了照顧到隱私性，儘可能減小其生命週期，即便被截取了，也不至於產生嚴重的後果。
注意：在客戶端 token 之下還加上一個 access_token， 主要是爲了讓具備不一樣生命週期的客戶端 token 最後在調用 api 的時候， 可以具備統一的認證方式。
4.四、pam_token
功能：
由已經登陸和認證的 PC 端生成的二維碼的原始串號（Pc Auth Mobile）。
主要步驟以下：
PC 上用戶已經完成認證，登陸了系統
PC 端生成一組和此用戶相關聯的 pam_token
PC 端將此 pam_token 的使用連接生成二維碼
移動端掃碼後，請求服務器，並和用戶信息關聯
移動端獲取 refresh_token(長時效的會話)
根據 refreshtoken 獲取 accesstoken
完成正常的接口調用工做
備註:
生存週期爲 2 分鐘, 2 分鐘後過時刪除
沒有被使用時, 每 1 分鐘變一次
被使用後, 馬上刪除掉
此種認證模式通常不會被使用到
4.五、map_token
功能：
由已經登陸的移動 app 來掃碼認證 PC 端系統，並完成 PC 端系統的登陸（Mobile Auth Pc）。
主要步驟：
移動端完成用戶身份的認證登陸 app
未登陸的 PC 生成匿名的 map_token
移動端掃碼後在 db 中生成 map_token 和用戶關聯（完成簽名）
db 同時針對此用戶生成 web_token
PC 端一直以 maptoken 爲參數查找此命名用戶的 webtoken
PC 端根據 webtoken 去獲取 accesstoken
後續正常的調用接口調用工做
備註:
生存週期爲 2 分鐘, 2 分鐘後過時刪除
沒有被使用時, 每 1 分鐘變一次
被使用後, 馬上刪除掉
五、小結與展望
本文所設計的基於 token 的身份認證系統，主要解決了以下的問題：
token 的分類問題
token 的隱私性參數設置問題
token 的使用場景問題
不一樣生命週期的 token 分層轉化關係
本文中提到的設計方法，在 應用層 中能夠適用於且不限於以下場景中：
用戶登陸
有時效的優惠券發放
有時效的邀請碼發放
有時效的二維碼受權
具備時效 手機 / 郵件 驗證碼
多個不一樣平臺調用同一套 API 接口
多個平臺使用同一個身份認證中心
至於更多的使用場景，就須要你們去發掘了。
本文做者：哈莫
cnblogs.com/beer/p/6029861.html
- END - 推薦案例
溫暖提示
爲了方便你們更好的學習，本公衆號常常分享一些完整的單個功能案例代碼給你們去練習， 若是本公衆號沒有你要學習的功能案例，你能夠聯繫小編（微信：xxf960513）提供你的小需求給我，我安排咱們這邊的開發團隊免費幫你完成你的案例。
注意：只能提單個功能的需求不能要求功能太多，好比要求用什麼技術，有幾個頁面，頁面要求怎麼樣？
請長按識別二維碼
想學習更多的java功能案例請關注
Java項目開發
若是你以爲這個案例以及咱們的分享思路不錯，對你有幫助，請分享給身邊更多須要學習的朋友。別忘了《留言+點在看》給做者一個鼓勵哦！
本文分享自微信公衆號 - web項目開發（javawebkaifa）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。