本文將從Web應(yīng)用 由傳統(tǒng)身份驗(yàn)證到基于Token的身份驗(yàn)證的演變過程的角度，介紹Session、Cookie、Token。

[[313415]]

很久以前，Web 應(yīng)用基本用作文檔的瀏覽，如網(wǎng)絡(luò)黃頁。既然僅僅是瀏覽，因此服務(wù)器不需要記錄具體用戶在某一段時間里都瀏覽了哪些文檔，每次請求都是一個新的HTTP協(xié)議，對服務(wù)器來說都是全新的。

基于Session的身份驗(yàn)證

隨著交互式Web應(yīng)用的興起，比如，購物等需要登錄的網(wǎng)站。引出了一個新的問題，那就是要記錄哪些用戶登錄了系統(tǒng)進(jìn)行了哪些操作，即要管理會話(什么是會話?簡單的講如果用戶需要登錄，那么就可以簡單的理解為會話，如果不需要登錄，那么就是簡單的連接。)，比如，不同用戶將不同商品加入到購物車中， 也就是說必須把每個用戶區(qū)分開。因?yàn)镠TTP請求是無狀態(tài)的，所以想出了一個辦法，那就是給每個用戶配發(fā)一個會話標(biāo)識(Session id)，簡單的講就是一個既不會重復(fù)，又不容易被找到規(guī)律以仿造的隨機(jī)字符串，使得每個用戶的收到的會話標(biāo)識都不一樣， 每次用戶從客戶端向服務(wù)端發(fā)起HTTP請求的時候，把這個字符串給一并發(fā)送過來， 這樣服務(wù)端就能區(qū)分開誰是誰了，至于客戶端(瀏覽器)如何保存這個“身份標(biāo)識”，一般默認(rèn)采用 Cookie 的方式，這個會話標(biāo)識(Session id)會存在客戶端的Cookie中。

雖然這樣解決了區(qū)分用戶的問題，但又引發(fā)了一個新的問題，那就是每個用戶(客戶端)只需要保存自己的會話標(biāo)識(Session id)，而服務(wù)端則要保存所有用戶的會話標(biāo)識(Session id)。 如果訪問服務(wù)端的用戶逐漸變多， 就需要保存成千上萬，甚至幾千萬個，這對服務(wù)器說是一個難以接受的開銷 。 再比如，服務(wù)端是由2臺服務(wù)器組成的一個集群， 小明通過服務(wù)器A登錄了系統(tǒng)， 那session id會保存在服務(wù)器A上， 假設(shè)小明的下一次請求被轉(zhuǎn)發(fā)到服務(wù)器B怎么辦? 服務(wù)器B可沒有小明 的 session id。

可能會有人講，如果使小明登錄時，始終在服務(wù)器A上進(jìn)行登錄(sticky session)，豈不解決了這個問題?那如果服務(wù)器A掛掉怎么辦呢? 還是會將小明的請求轉(zhuǎn)發(fā)到服務(wù)器B上。

如此一來，那只能做集群間的 session 復(fù)制共享了， 就是把 session id 在兩個機(jī)器之間進(jìn)行復(fù)制，如下圖，但這對服務(wù)器的性能和內(nèi)存提出了巨大的挑戰(zhàn)。

因此，又想到如果將所有用戶的Session集中存儲呢，也就想到了緩存服務(wù)Memcached——由于 Memcached 是分布式的內(nèi)存對象緩存系統(tǒng)，因此可以用來實(shí)現(xiàn) Session 同步。把session id 集中存儲到一臺服務(wù)器上， 所有的服務(wù)器都來訪問這個地方的數(shù)據(jù)， 如此就避免了復(fù)制的方式， 但是這種“集萬千寵愛于一身”使得又出現(xiàn)了單點(diǎn)故障的可能， 就是說這個負(fù)責(zé)存儲 session 的服務(wù)器掛了， 所有用戶都得重新登錄一遍， 這是用戶難以接受的。

那么索性存儲Session的服務(wù)器也搞成集群，增加其可靠性，避免單點(diǎn)故障，但不管如何，Session 引發(fā)出來的問題層出不窮。

于是有人就在思考， 為什么服務(wù)端必須要保存這session呢， 只讓每個客戶端去保存不行嗎?可是服務(wù)端如果不保存這些session id ，又將如何驗(yàn)證客戶端發(fā)送的 session id 的確是服務(wù)端生成的呢? 如果不驗(yàn)證，服務(wù)端無法判斷是否是合法登錄的用戶，對，這里的問題是驗(yàn)證， session 只是解決這個驗(yàn)證問題的而產(chǎn)生的一個解決方案，是否還有其它方案呢?

基于Token 的身份驗(yàn)證

例如， 小明已經(jīng)登錄了系統(tǒng)，服務(wù)端給他發(fā)一個令牌(Token)， 里邊包含了小明的 user id， 后續(xù)小明再次通過 Http 請求訪問服務(wù)器的時候， 把這個 Token 通過 Http header 帶過來不就可以了。

服務(wù)端需要驗(yàn)證 Token是自己生成的，而非偽造的。假如不驗(yàn)證任何人都可以偽造，那么這個令牌(token)和 session id沒有本質(zhì)區(qū)別，如何讓別人偽造不了?那就對數(shù)據(jù)做一個簽名(Sign)吧， 比如說服務(wù)端用 HMAC-SHA256 加密算法，再加上一個只有服務(wù)端才知道的密鑰， 對數(shù)據(jù)做一個簽名， 把這個簽名和數(shù)據(jù)一起作為 Token 發(fā)給客戶端， 客戶端收到 Token 以后可以把它存儲起來，比如存儲在 Cookie 里或者 Local Storage 中，由于密鑰除了服務(wù)端任何其他用戶都不知道， 就無法偽造令牌(Token)。

如此一來，服務(wù)端就不需要保存 Token 了， 當(dāng)小明把這個Token發(fā)給服務(wù)端時，服務(wù)端使用相同的HMAC-SHA256 算法和相同的密鑰，對數(shù)據(jù)再計(jì)算一次簽名， 和 Token 中的簽名做個對比， 如果相同，說明小明已經(jīng)登錄過了， 即驗(yàn)證成功。若不相同， 那么說明這個請求是偽造的。

這樣一來， 服務(wù)端只需要生成 Token，而不需要保存Token， 只是驗(yàn)證Token就好了 ，也就實(shí)現(xiàn)了時間換取空間(CPU計(jì)算時間換取session 存儲空間)。沒了session id 的限制， 當(dāng)用戶訪問量增大， 直接加機(jī)器就可以輕松地做水平擴(kuò)展，也極大的提高了可擴(kuò)展性。