cookie 與 request headers, 本身都是 request 請求的信息載體
1. 放 cookie 里:
缺點: cookie 本身有存儲容量上限小 5kb,
缺點: 每次 request 請求都攜帶 cookie,
缺點: cookie 不能跨域名, 不能實現(xiàn)點單登錄
優(yōu)點: 服務(wù)端通過設(shè)置 httpOnly 客戶端不可以修改密匙
優(yōu)點: 想的少, 放里就完了, 請求每次都攜帶
2. 放 request headers 里:
優(yōu)點: 如果存在 sessionStorage 里, 容量上限 5mb,
優(yōu)點: 每次 request 請求可以判斷是否攜帶,
優(yōu)點: 可以跨域名, 可以實現(xiàn)點單登錄
缺點: 無 httpOnly 功能, 客戶端可以修改
缺點: 靈活意味著事兒也多
問題: 登錄解決方案 session VS jwt:
session 與 jwt 本身都是密匙, 都存放著某些敏感信息, 都需要設(shè)置過期時間, 不同的是
session:
sessionId 本身是一個密匙, 是通過服務(wù)端動態(tài)生成的
sessionId 本身不帶有 用戶信息, 需要用 sessionId 跑到 redis 里拿到 userInfo
session 對象是通過服務(wù)端管理的, 一般都放在 redis 里
關(guān)于單點登錄方面, 放在 cookie 里不能實現(xiàn), 放在 request headers 可以實現(xiàn)
session 本身依賴 redis 管理, 所以可以在服務(wù)端操作用戶登錄狀態(tài)
業(yè)內(nèi)公認(rèn) 可拓展性 jwt 比 session 好, 因為 jwt 本身就攜帶 userInfo 信息, 可以在不同的域名里傳遞.
session 安全性高, 因為 sessionId 在客戶端存的內(nèi)容比 jwt 少, 且 sessionId 一般存在 cookie 里, cookie 可以設(shè)置 httpOnly. jwt 一般存在 sessionStorage 里, 客戶端可以修改
RESTful 規(guī)范要求 請求無狀態(tài) 規(guī)范, jwt 要本身就是無狀態(tài)的
session 請求攜帶量小, 但每次請求都攜帶, 之后還要去 redis 里去查 userInfo. jwt 請求攜帶量大, request 后不需要再去 redis 里查找, 本身就是 userInfo, 用空間換時間.
時效性應(yīng)用場景: 用戶在系統(tǒng)中濫用權(quán)限, 管理員對用戶降級處理. 賬號在異地登錄, 使賬號強(qiáng)制登出. 這些場景 session 比 jwt 好用.
jwt( json web token ):
jwt 本身是一個密匙, 是通過服務(wù)端加密算出的
jwt 本身就攜帶 用戶信息, 所以不需要用到 redis
token 字符串里包含所有的 用戶信息, 不需要 redis, 所以服務(wù)端也很難管理( 如: 強(qiáng)制登出某用戶, 若用黑名單實現(xiàn)需要記錄此用戶的下次請求動作 )
關(guān)于單點登錄方面, 放在 cookie 里不能實現(xiàn), 放在 request headers 可以實現(xiàn)
jwt 不需要 redis, 在服務(wù)端管理比較難
鏈接：http://www.reibang.com/p/d007b9ce4e28
