目錄

目錄cookiesessiontoken

cookie

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

基于 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 是被信任的, 無須再次認證身份. 否則, 需要重新進入身份認證流程.

缺點:

簡而言之, session 有如用戶信息檔案表, 里面包含了用戶的認證信息和登錄狀態等信息. 而 cookie 就是用戶通行證.

token

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

由其組成可以看出, 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 項目會為整個云平臺提供身份認證服務.

缺點: