1   概述

在存在賬號體系的資訊系統中,對身份的鑑定是非常重要的事情。

隨著移動網際網路時代到來,客戶端的型別越來越多, 逐漸出現了 一個伺服器,N個客戶端的格局 。

不同的客戶端產生了不同的使用者使用場景,這些場景:

  1. 有不同的環境安全威脅
  2. 不同的會話生存週期
  3. 不同的使用者許可權控制體系
  4. 不同級別的介面呼叫方式

綜上所述,它們的身份認證方式也存在一定的區別。

本文將使用一定的篇幅對這些場景進行一些分析和梳理工作。

.

2   使用場景

下面是一些在IT服務常見的一些使用場景:

  1. 使用者在web瀏覽器端登入系統,使用系統服務
  2. 使用者在手機端(Android/iOS)登入系統,使用系統服務
  3. 使用者使用開放介面登入系統,呼叫系統服務
  4. 使用者在PC處理登入狀態時通過手機掃碼授權手機登入(使用得比較少)
  5. 使用者在手機處理登入狀態進通過手機掃碼授權PC進行登入(比較常見)

通過對場景的細分,得到如下不同的認證token類別:

  1. 原始賬號密碼類別
    • 使用者名稱和密碼
    • API應用ID/KEY
  2. 會話ID類別
    • 瀏覽器端token
    • 移動端token
    • API應用token
  3. 介面呼叫類別
    • 介面訪問token
  4. 身份授權類別
    • PC和移動端相互授權的token

3   token的類別

不同場景的token進行如下幾個維度的對比:

天然屬性 對比:

  1. 使用成本

    本認證方式在使用的時候,造成的不便性。比如:

    • 賬號密碼需要使用者開啟頁面然後逐個鍵入
    • 二維碼需要使用者掏出手機進行掃碼操作
  2. 變化成本

    本認證方式,token發生變化時,使用者需要做出的相應更改的成本:

    • 使用者名稱和密碼發生變化時,使用者需要額外記憶和重新鍵入新密碼
    • API應用ID/KEY發生變化時,第三方應用需要重新在程式碼中修改並部署
    • 授權二維碼發生變化時,需要使用者重新開啟手機應用進行掃碼
  3. 環境風險

    • 被偷窺的風險
    • 被抓包的風險
    • 被偽造的風險

可調控屬性 對比:

  1. 使用頻率
    • 在網路中傳送的頻率
  2. 有效時間
    • 此token從建立到終結的生存時間

最終的目標:安全和影響。

安全和隱私性主要體現在:

  • token 不容易被竊取和盜用(通過對傳送頻率控制)
  • token 即使被竊取,產生的影響也是可控的(通過對有效時間控制)

關於隱私及隱私破壞後的後果,有如下的基本結論:

  1. 曝光頻率高的容易被截獲
  2. 生存週期長的在被截獲後產生的影響更嚴重和深遠

遵守如下原則:

  1. 變化成本高的token不要輕易變化
  2. 不輕易變化的token要減少曝光頻率(網路傳輸次數)
  3. 曝光頻率高的token的生存週期要儘量短

將各類token的固有特點及可控屬性進行調控後, 對每個指標進行量化評分(1~5分),我們可以得到如下的對比表:


備註:

  • user_name/passwd 和 app_id/app_key 是等價的效果

4   token的層級關係

參考上一節的對比表,可以很容易對這些不同用途的token進行分層,主要可以分為4層:

  1. 密碼層

    最傳統的使用者和系統之間約定的數字身份認證方式

  2. 會話層

    使用者登入後的會話生命週期的會話認證

  3. 呼叫層

    使用者在會話期間對應用程式介面的呼叫認證

  4. 應用層

    使用者獲取了介面訪問呼叫許可權後的一些場景或者身份認證應用

token的分層圖如下:

在一個多客戶端的資訊系統裡面,這些token的產生及應用的內在聯絡如下:

  1. 使用者輸入使用者名稱和使用者口令進行一次性認證
  2. 在 不同 的終端裡面生成擁有 不同 生命週期的會話token
  3. 客戶端會話token從服務端交換生命週期短但曝光 頻繁 的介面訪問token
  4. 會話token可以生成和重新整理延長 access_token 的生存時間
  5. access_token可以生成生存週期最短的用於授權的二維碼的token

使用如上的架構有如下的好處:

  1. 良好的統一性。可以解決不同平臺上認證token的生存週期的 歸一化 問題
  2. 良好的解耦性。核心介面呼叫伺服器的認證 access_token 可以完成獨立的實現和部署
  3. 良好的層次性。不同平臺的可以有完全不同的使用者許可權控制系統,這個控制可以在 會話層 中各平臺解決掉

4.1   賬號密碼

廣義的 賬號/密碼 有如下的呈現方式:

  1. 傳統的註冊使用者名稱和密碼
  2. 應用程式的app_id/app_key

它們的特點如下:

  1. 會有特別的意義

    比如:使用者自己為了方便記憶,會設定有一定含義的賬號和密碼。

  2. 不常修改

    賬號密碼對使用者有特別含義,一般沒有特殊情況不會願意修改。 而app_id/app_key則會寫在應用程式中,修改會意味著重新發布上線的成本

  3. 一旦洩露影響深遠

    正因為不常修改,只要洩露了基本相當於使用者的網路身份被洩露,而且只要沒被察覺這種身份盜用就會一直存在

所以在認證系統中應該儘量減少傳輸的機會,避免洩露。

4.2   客戶端會話token

功能:充當著session的角色,不同的客戶端有不同的生命週期。

使用步驟:

  1. 使用者使用賬號密碼,換取會話token

不同的平臺的token有不同的特點。

Web平臺生存週期短

主要原因:

  1. 環境安全性

    由於web登入環境一般很可能是公共環境,被他人盜取的風險值較大

  2. 輸入便捷性

    在PC上使用鍵盤輸入會比較便捷

移動端生存週期長

主要原因:

  1. 環境安全性

    移動端平臺是個人使用者極其私密的平臺,它人接觸的機會不大

  2. 輸入便捷性

    在移動端上使用手指在小螢幕上觸控輸入體驗差,輸入成本高

4.3   access_token

功能:服務端應用程式api介面訪問和呼叫的憑證。

使用步驟:

  1. 使用具有較長生命週期的會話token來換取此介面訪問token。

其曝光頻率直接和介面呼叫頻率有關,屬於高頻使用的憑證。 為了照顧到隱私性,儘量減少其生命週期,即使被截取了,也不至於產生嚴重的後果。

注意:在客戶端token之下還加上一個access_token, 主要是為了讓具有不同生命週期的客戶端token最後在呼叫api的時候, 能夠具有統一的認證方式。

4.4   pam_token

功能:由已經登入和認證的PC端生成的二維碼的原始串號(Pc Auth Mobile)。

主要步驟如下:

  1. PC上使用者已經完成認證,登入了系統
  2. PC端生成一組和此使用者相關聯的pam_token
  3. PC端將此pam_token的使用連結生成二維碼
  4. 移動端掃碼後,請求伺服器,並和使用者資訊關聯
  5. 移動端獲取refresh_token(長時效的會話)
  6. 根據 refresh_token 獲取 access_token
  7. 完成正常的介面呼叫工作

備註:

  • 生存週期為2分鐘,2分鐘後過期刪除
  • 沒有被使用時,每1分鐘變一次
  • 被使用後,立刻刪除掉
  • 此種認證模式一般不會被使用到

4.5   map_token

功能:由已經登入的移動app來掃碼認證PC端系統,並完成PC端系統的登入(Mobile Auth Pc)。

主要步驟:

  1. 移動端完成使用者身份的認證登入app
  2. 未登入的PC生成匿名的 map_token
  3. 移動端掃碼後在db中生成 map_token 和使用者關聯(完成簽名)
  4. db同時針對此使用者生成 web_token
  5. PC端一直以 map_token 為引數查詢此命名使用者的 web_token
  6. PC端根據 web_token 去獲取 access_token
  7. 後續正常的呼叫介面呼叫工作

備註:

  • 生存週期為2分鐘,2分鐘後過期刪除
  • 沒有被使用時,每1分鐘變一次
  • 被使用後,立刻刪除掉

5   小結與展望

本文所設計的基於token的身份認證系統,主要解決了如下的問題:

  1. token的分類問題
  2. token的隱私性引數設定問題
  3. token的使用場景問題
  4. 不同生命週期的token分層轉化關係

本文中提到的設計方法,在 應用層 中可以適用於且不限於如下場景中:

  1. 使用者登入
  2. 有時效的優惠券發放
  3. 有時效的邀請碼發放
  4. 有時效的二維碼授權
  5. 具有時效 手機/郵件 驗證碼
  6. 多個不同平臺呼叫同一套API介面
  7. 多個平臺使用同一個身份認證中心

至於更多的使用場景,就需要大家去發掘了。