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

[[313415]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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