1. sessionjavascript
session和cookie的目的相同,都是爲了克服http協議無狀態的缺陷,但完成的方法不一樣。session經過cookie,在客戶端保存session id,而將用戶的其餘會話消息保存在服務端的session對象中,與此相對的,cookie須要將全部信息都保存在客戶端。所以cookie存在着必定的安全隱患,例如本地cookie中保存的用戶名密碼被破譯,或cookie被其餘網站收集(例如:1. appA主動設置域B cookie,讓域B cookie獲取;2. XSS,在appA上經過javascript獲取document.cookie,並傳遞給本身的appB)。
java
2. jwt:react
真正講明白的一篇文章: https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authenticationweb
0. 算法
23 Oct 2015數據庫
jwt 不只可用於驗證用戶還可用於 server 間通訊驗證api
app server 多是分佈式的, 有不少 server, 在一個 server 上登陸了,
其餘的沒登錄, 須要額外工具來解決這個問題(sticky sessions)瀏覽器
app 使用 RESTfull api 來獲取數據, RESTful api 的原則是 stateless, 但使用 session, 使用 session 和 cookies 會引入 state; 另外, 當 API server 與 app server
多是兩個 server, 須要 容許 CORS(Cross-Origin Resource Sharing), 可是 cookies 只能在同一個 domain 中使用緩存
app 可能須要下游服務, 每一個 server 都要處理 cookie(???)安全
JWT 方案不使用 session 基於 token.
用戶註冊以後, 服務器生成一個 JWT token返回給瀏覽器, 瀏覽器向服務器請求
數據時將 JWT token 發給服務器, 服務器用 signature 中定義的方式解碼
JWT 獲取用戶信息.
一個 JWT token包含3部分:
1. header: 告訴咱們使用的算法和 token 類型
2. Payload: 必須使用 sub
key 來指定用戶 ID, 還能夠包括其餘信息
好比 email, username 等.
3. Signature: 用來保證 JWT 的真實性. 可使用不一樣算法
1. 和Session方式存儲id的差別
Session方式存儲用戶id的最大弊病在於要佔用大量服務器內存,對於較大型應用而言可能還要保存許多的狀態。通常而言,大型應用還須要藉助一些KV數據庫和一系列緩存機制來實現Session的存儲。
而JWT方式將用戶狀態分散到了客戶端中,能夠明顯減輕服務端的內存壓力。除了用戶id以外,還能夠存儲其餘的和用戶相關的信息,例如該用戶是不是管理員、用戶所在的分桶(見[《你所應該知道的A/B測試基礎》一文](/2015/08/27/introduction-to-ab-testing/)等。
雖然說JWT方式讓服務器有一些計算壓力(例如加密、編碼和解碼),可是這些壓力相比磁盤I/O而言或許是半斤八兩。具體是否採用,須要在不一樣場景下用數聽說話。
2. http://blog.rainy.im/2015/06/10/react-jwt-pretty-good-practice/
區別(仔細揣摩)
##1.
這麼基礎的問題,竟然仍是沒人說到點子上,最關鍵的一點是:
* Session的狀態是存儲在服務器端,客戶端只有session id;而Token的狀態是存儲在客戶端
其它細枝末節的區別,所有是由這一點形成的。
就沒人想過爲何token-based的authentication須要一堆secret key來幹嗎麼?
由於狀態信息所有是放在客戶端,爲了不被篡改,因而須要用密碼學的方法來簽名/加密。
能夠本身去這裏玩玩JWT的Debugger:
http://jwt.io/
一進去你就會注意到兩點:
1. Token解碼後就包含全部登錄信息
2. Token你隨便改一位都會提示無效
##2.
session 和 token 就是個詞而已…… 廣義來講一切維護用戶狀態的技術都是session,一切動態生成的服務端有能力鑑別真假而自己無涵義的字符串都是token |
更多的詳見:
http://www.slideshare.net/derekperkins/authentication-cookies-vs-jwts-and-why-youre-doing-it-wrong