cookie

Web Application 一般以 HTTP 協(xié)議作為傳輸協(xié)議, 但 HTTP 協(xié)議是無狀態(tài)的. 也就是說 server-side 與 client-side 一旦數(shù)據(jù)交換完畢后坏瞄，兩者之間的連接就會被關(guān)閉. client-side 再次發(fā)送請求時, 需要建立新的連接, 這就意味著 server-side 和 client-side 兩者之間無法通過 HTTP 的連接來實(shí)現(xiàn) 會話跟蹤. 顯然, 這是不合理的, 因?yàn)檫@樣無法保證完成一次 Web Application 業(yè)務(wù)流程中所產(chǎn)生的若干次 請求/響應(yīng) 操作的原子性, 從而會導(dǎo)致業(yè)務(wù)邏輯混亂. cookie 就是為了解決這一問題所引入的 會話跟蹤機(jī)制.

實(shí)現(xiàn)原理: 由 server-side 為 client-side 發(fā)放一張通行證, 并以此來認(rèn)證 client-side 的身份(出于安全性的考慮, 這張通行證一般是臨時的). 而這些通行證就是 cookie, 本質(zhì)上 cookie 就是一小段文本信息, 里面包含了有如 session_id/login-status/token 等認(rèn)證相關(guān)數(shù)據(jù).

session

基于 session 的用戶認(rèn)證借助于請求體對象 req 中的 session 數(shù)據(jù)來完成.

實(shí)現(xiàn)原理: 當(dāng) client-side 請求 server-side 并通過身份認(rèn)證后, server-side 就會生成并保存身份認(rèn)證相關(guān)的 session 數(shù)據(jù), 并將對應(yīng)的 sesssion_id 寫入 cookie 然后再響應(yīng)到 client-side, client-side 會把 cookie 文件保存在本地. 此后, client-side 的所有請求都會附帶該 session_id, 以確定 server-side 是否存在對應(yīng)的 session 數(shù)據(jù)以及檢驗(yàn) session 數(shù)據(jù)中的 login-status. 如果存在且 login-status 為 True, 則證明 client-side 是被信任的, 無須再次認(rèn)證身份. 否則, 需要重新進(jìn)入身份認(rèn)證流程.

缺點(diǎn):

server-side 保存 session 數(shù)據(jù)會增加運(yùn)維和存儲開銷
因?yàn)橐粋€ session_id 只能被保存有對應(yīng) session 數(shù)據(jù)的 server-side 完成認(rèn)證, 所以在擁有多臺 server-side 集群架構(gòu)的場景中會降低其擴(kuò)展性.
如果原生 App 不具備 cookie 功能模塊, 就會加大其接入 session 認(rèn)證后端的難度.
簡而言之, session 有如用戶信息檔案表, 里面包含了用戶的認(rèn)證信息和登錄狀態(tài)等信息. 而 cookie 就是用戶通行證.

token

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

uid: 用戶唯一身份標(biāo)識
time: 當(dāng)前時間的時間戳
sign: 簽名, 使用 hash/encrypt 壓縮成定長的十六進(jìn)制字符串玖翅，以防止第三方惡意拼接
固定參數(shù)(可選): 將一些常用的固定參數(shù)加入到 token 中是為了避免重復(fù)查庫
由其組成可以看出, token 的認(rèn)證方式類似于臨時的證書簽名, 并且是一種 server-side 無狀態(tài)的認(rèn)證方式, 非常適合于 REST API 的場景. 所謂無狀態(tài)就是 server-side 并不會保存身份認(rèn)證相關(guān)的數(shù)據(jù), token 只被保存在 client-side 中的 cookie 或 localstorage(數(shù)據(jù)庫).

實(shí)現(xiàn)原理: 當(dāng) client-side 發(fā)送請求 server-side 并完成身份認(rèn)證后, server-side 會生成但不保存一個 token, 而是將 token 以 cookie 或其他形式響應(yīng)給 client-side. 此后 client-side 發(fā)送請求時都會在 Request-Header 中附帶 token, server-side 收到 token 后再分發(fā)給其他的 身份認(rèn)證服務(wù) 負(fù)責(zé)處理認(rèn)證相關(guān)的業(yè)務(wù). E.G. Openstack 中的 Keystone 項(xiàng)目會為整個云平臺提供身份認(rèn)證服務(wù).

缺點(diǎn):

因?yàn)?token 一般都是 hash/encrypt 的字符串, 所以會額外附加 加密/解密 的性能開銷
有些加密方式同樣存在安全隱患