快速了解 session/token/cookie 認證方式目錄cookiesessiontoken

<a href="#%E7%9B%AE%E5%BD%95">目錄</a>

<a href="#cookie">cookie</a>

<a href="#session">session</a>

<a href="#token">token</a>

Web Application 一般以 HTTP 協定作為傳輸協定, 但 HTTP 協定是無狀态的. 也就是說 server-side 與 client-side 一旦資料交換完畢後，兩者之間的連接配接就會被關閉. client-side 再次發送請求時, 需要建立新的連接配接, 這就意味着 server-side 和 client-side 兩者之間無法通過 HTTP 的連接配接來實作 會話跟蹤. 顯然, 這是不合理的, 因為這樣無法保證完成一次 Web Application 業務流程中所産生的若幹次 請求/響應 操作的原子性, 進而會導緻業務邏輯混亂. cookie 就是為了解決這一問題所引入的 會話跟蹤機制.

實作原理: 由 server-side 為 client-side 發放一張通行證, 并以此來認證 client-side 的身份(出于安全性的考慮, 這張通行證一般是臨時的). 而這些通行證就是 cookie, 本質上 cookie 就是一小段文本資訊, 裡面包含了有如 session_id/login-status/token 等認證相關資料.

基于 session 的使用者認證借助于請求體對象 req 中的 session 資料來完成.

實作原理: 當 client-side 請求 server-side 并通過身份認證後, server-side 就會生成并儲存身份認證相關的 session 資料, 并将對應的 sesssion_id 寫入 cookie 然後再響應到 client-side, client-side 會把 cookie 檔案儲存在本地. 此後, client-side 的所有請求都會附帶該 session_id, 以确定 server-side 是否存在對應的 session 資料以及檢驗 session 資料中的 login-status. 如果存在且 login-status 為 True, 則證明 client-side 是被信任的, 無須再次認證身份. 否則, 需要重新進入身份認證流程.

缺點:

server-side 儲存 session 資料會增加運維和存儲開銷

因為一個 session_id 隻能被儲存有對應 session 資料的 server-side 完成認證, 是以在擁有多台 server-side 叢集架構的場景中會降低其擴充性.

如果原生 App 不具備 cookie 功能子產品, 就會加大其接入 session 認證後端的難度.

簡而言之, session 有如使用者資訊檔案表, 裡面包含了使用者的認證資訊和登入狀态等資訊. 而 cookie 就是使用者通行證.

token(令牌) 由 uid+time+sign[+固定參數] 組成:

uid: 使用者唯一身份辨別

time: 目前時間的時間戳

sign: 簽名, 使用 hash/encrypt 壓縮成定長的十六進制字元串，以防止第三方惡意拼接

固定參數(可選): 将一些常用的固定參數加入到 token 中是為了避免重複查庫

由其組成可以看出, token 的認證方式類似于臨時的證書簽名, 并且是一種 server-side 無狀态的認證方式, 非常适合于 REST API 的場景. 所謂無狀态就是 server-side 并不會儲存身份認證相關的資料, token 隻被儲存在 client-side 中的 cookie 或 localstorage(資料庫).

實作原理: 當 client-side 發送請求 server-side 并完成身份認證後, server-side 會生成但不儲存一個 token, 而是将 token 以 cookie 或其他形式響應給 client-side. 此後 client-side 發送請求時都會在 Request-Header 中附帶 token, server-side 收到 token 後再分發給其他的 身份認證服務 負責處理認證相關的業務. E.G. Openstack 中的 Keystone 項目會為整個雲平台提供身份認證服務.

因為 token 一般都是 hash/encrypt 的字元串, 是以會額外附加 加密/解密 的性能開銷

有些加密方式同樣存在安全隐患