一、引言
之前寫過一篇 基于SpringBoot和Redis實作Token權限認證 的文章，主要講解如何使用Token做權限校驗，但并沒有對Cookie、Session和Token做基本的講解，下面就對這三者做一個介紹，完全是用于友善了解，便于記憶和差別，就醬~
二、Session發展史
1、第一階段
long long ago，Web 基本上就是文檔的浏覽而已， 既然是浏覽，作為伺服器， 不需要記錄誰在某一段時間裡都浏覽了什麼文檔，每次請求都是一個新的 HTTP 協定， 就是請求加響應， 在伺服器端不用記住是誰剛剛發了HTTP請求，每個請求對伺服器來說都是全新的。
2、第二階段
但是随着互動式 Web 應用的興起，像線上購物網站，需要登入的網站等等，馬上就面臨一個問題，那就是要管理會話，必須記住哪些人登入系統， 哪些人往自己的購物車中放商品， 也就是說伺服器必須要把每個人區分開，這是一個不小的挑戰，因為HTTP請求是無狀态的，是以想出的辦法就是給大家發一個會話辨別(session id)， 說白了就是一個随機的字串，每個人收到的都不一樣， 每次大家向我發起HTTP請求的時候，把這個字元串給一并捎過來， 這樣我就能區分開誰是誰了。
3、第三階段
這樣大家很嗨皮了，可是伺服器就不嗨皮了，每個人隻需要儲存自己的session id，而伺服器要儲存所有人的session id ！ 如果通路伺服器多了， 就得有成千上萬，甚至幾十萬個。這對伺服器來說是一個巨大的開銷 ， 嚴重的限制了伺服器擴充能力， 比如說我用兩個機器組成了一個叢集， 小Q通過機器A登入了系統， 那session id會儲存在機器A上，假設小Q的下一次請求被轉發到機器B怎麼辦？ 機器B可沒有小F的 session id啊。
有時候會采用一點小伎倆： session sticky ， 就是讓小Q的請求一直粘連在機器A上， 但是這也不管用， 要是機器A挂掉了， 還得轉到機器B去。
那隻好做 session 的複制了， 把session id 在兩個機器之間搬來搬去， 快累死了。
後來有個叫MemCached的支了招： 把session id 集中存儲到一個地方， 所有的機器都來通路這個地方的資料， 這樣一來，就不用複制了， 但是這樣增加了單點失敗的可能性， 要是那個負責 session 的機器MemCached挂了， 所有人都得重新登入一遍， 估計得被人罵死。
也嘗試把這個單點的機器也搞出叢集，增加可靠性， 但不管如何， 這小小的 session 對我來說是一個沉重的負擔
4、第四階段
于是有人就一直在思考， 我為什麼要儲存這可惡的session呢， 隻讓每個用戶端去儲存該多好？
可是如果不儲存這些 session id , 怎麼驗證用戶端發給我的session id 的确是我生成的呢？ 如果不去驗證，我們都不知道他們是不是合法登入的使用者， 那些不懷好意的家夥們就可以僞造session id , 為所欲為了。 嗯，對了，關鍵點就是驗證 ！
比如說， 小Q已經登入了系統， 我給他發一個令牌(token)， 裡邊包含了小Q的 user id， 下一次小Q 再次通過Http 請求通路我的時候， 把這個 token 通過 Http header 帶過來不就可以了。
不過這和 session id沒有本質差別啊， 任何人都可以可以僞造， 是以我得想點兒辦法， 讓别人僞造不了。
那就對資料做一個簽名吧， 比如說我用 HMAC-SHA256 算法，加上一個隻有我才知道的密鑰，對資料做一個簽名，把這個簽名和資料一起作為token ， 由于密鑰别人不知道， 就無法僞造token了。
這個 token 我不儲存， 當小Q把這個 token 給我發過來的時候，我再用同樣的HMAC-SHA256 算法和同樣的密鑰，對資料再計算一次簽名， 和 token 中的簽名做個比較， 如果相同， 我就知道小Q已經登入過了，并且可以直接取到小Q的user id , 如果不相同，資料部分肯定被人篡改過， 我就告訴發送者： 對不起，沒有認證。
Token 中的資料是明文儲存的（雖然我會用Base64做下編碼， 但那不是加密）， 還是可以被别人看到的， 是以我不能在其中儲存像密碼這樣的敏感資訊。
當然， 如果一個人的 token 被别人偷走了， 那我也沒辦法， 我也會認為小偷就是合法使用者， 這其實和一個人的 session id 被别人偷走是一樣的。
這樣一來， 我就不儲存session id 了， 我隻是生成 token , 然後驗證 token ，我用我的CPU計算時間擷取了我的session 存儲空間 ！
解除了session id這個負擔， 可以說是無事一身輕， 我的機器叢集現在可以輕松地做水準擴充， 使用者通路量增大， 直接加機器就行。 這種無狀态的感覺實在是太好了！
三、Cookie
1、Cookie
cookie 是一個非常具體的東西，指的就是浏覽器裡面能永久存儲的一種資料，僅僅是浏覽器實作的一種資料存儲功能。
cookie由伺服器生成，發送給浏覽器，浏覽器把cookie以kv形式儲存到某個目錄下的文本檔案内，下一次請求同一網站時會把該cookie發送給伺服器。由于cookie是存在用戶端上的，是以浏覽器加入了一些限制確定cookie不會被惡意使用，同時不會占據太多磁盤空間，是以每個域的cookie數量是有限的。
2、再說Session
session 從字面上講，就是會話。這個就類似于你和一個人交談，你怎麼知道目前和你交談的是張三而不是李四呢？對方肯定有某種特征（長相等）表明他就是張三。
session 也是類似的道理，伺服器要知道目前發請求給自己的是誰。為了做這種區分，伺服器就要給每個用戶端配置設定不同的“身份辨別”，然後用戶端每次向伺服器發請求的時候，都帶上這個“身份辨別”，伺服器就知道這個請求來自于誰了。至于用戶端怎麼儲存這個“身份辨別”，可以有很多種方式，對于浏覽器用戶端，大家都預設采用 cookie 的方式。
伺服器使用session把使用者的資訊臨時儲存在了伺服器上，使用者離開網站後session會被銷毀。這種使用者資訊存儲方式相對cookie來說更安全，可是session有一個缺陷：如果web伺服器做了負載均衡，那麼下一個操作請求到了另一台伺服器的時候session會丢失。
四、Token
在Web領域基于Token的身份驗證随處可見。在大多數使用Web API的網際網路公司中，token 是多使用者下處理認證的最佳方式。
以下幾點特性會讓你在程式中使用基于Token的身份驗證
（1）、無狀态、可擴充
（2）、支援移動裝置
（3）、跨程式調用
（4）、安全
1、Token的起源
在介紹基于Token的身份驗證的原理與優勢之前，不妨先看看之前的認證都是怎麼做的。
（1）、基于伺服器的驗證
我們都是知道HTTP協定是無狀态的，這種無狀态意味着程式需要驗證每一次請求，進而辨識用戶端的身份。在這之前，程式都是通過在服務端存儲的登入資訊來辨識請求的。這種方式一般都是通過存儲Session來完成。随着Web應用程式，以及移動端的興起，這種驗證的方式逐漸暴露出了問題。尤其是在可擴充性方面。
（2）、基于伺服器驗證方式暴露的一些問題
Seesion：每次認證使用者發起請求時，伺服器需要去建立一個記錄來存儲資訊。當越來越多的使用者發
請求時，記憶體的開銷也會不斷增加。
可擴充性：在服務端的記憶體中使用Seesion存儲登入資訊，伴随而來的是可擴充性問題。
CORS(跨域資源共享)：當我們需要讓資料跨多台移動裝置上使用時，跨域資源的共享會是一個讓人
頭疼的問題。在使用Ajax抓取另一個域的資源，就可以會出現禁止請求的情況。
CSRF(跨站請求僞造)：使用者在通路銀行網站時，他們很容易受到跨站請求僞造的攻擊，并且能夠被
利用其通路其他的網站。
在這些問題中，可擴充行是最突出的。是以我們有必要去尋求一種更有行之有效的方法。
2、基于Token的驗證原理
基于Token的身份驗證是無狀态的，我們不将使用者資訊存在伺服器或Session中。這種概念解決了在服務端存儲資訊時的許多問題，NoSession意味着你的程式可以根據需要去增減機器，而不用去擔心使用者是否登入。
基于Token的身份驗證的過程如下:
第一步：使用者通過使用者名和密碼發送請求。
第二步：程式驗證。
第三步：程式傳回一個簽名的 token 給用戶端。
第四步：用戶端儲存 token，并且每次用于每次發送請求。
第五步：服務端驗證 token 并傳回資料。
每一次請求都需要token。token應該在HTTP的頭部發送，進而保證了Http請求無狀态。我們同樣通過設定伺服器屬性Access-Control-Allow-Origin:* ，讓伺服器能接受到來自所有域的請求。需要注意的是，在ACAO頭部标明(designating)*時，不得帶有像HTTP認證，用戶端SSL證書和cookies的證書。
實作思路：
使用者登入校驗，校驗成功後就傳回Token給用戶端。
用戶端收到資料後儲存在用戶端
用戶端每次通路API是攜帶Token到伺服器端。
伺服器端采用filter過濾器校驗。校驗成功則傳回請求資料，校驗失敗則傳回錯誤碼
當我們在程式中認證了資訊并取得token之後，我們便能通過這個Token做許多的事情。
我們甚至能基于建立一個基于權限的token傳給第三方應用程式，這些第三方程式能夠擷取到我們的資料（當然隻有在我們允許的特定的token）
3、Tokens的優勢
（1）、無狀态、可擴充
在用戶端存儲的Tokens是無狀态的，并且能夠被擴充。基于這種無狀态和不存儲Session資訊，負載均衡器能夠将使用者資訊從一個服務傳到其他伺服器上。
如果我們将已驗證的使用者的資訊儲存在Session中，則每次請求都需要使用者向已驗證的伺服器發送驗證資訊(稱為Session親和性)。使用者量大時，可能會造成 一些擁堵。
但是不要着急。使用tokens之後這些問題都迎刃而解，因為tokens自己hold住了使用者的驗證資訊。
（2）、安全性
請求中發送token而不再是發送cookie能夠防止CSRF(跨站請求僞造)。即使在用戶端使用cookie存儲token，cookie也僅僅是一個存儲機制而不是用于認證。不将資訊存儲在Session中，讓我們少了對session操作。
token是有時效的，一段時間之後使用者需要重新驗證。我們也不一定需要等到token自動失效，token有撤回的操作，通過token revocataion可以使一個特定的token或是一組有相同認證的token無效。
（3）、可擴充性
Token能夠建立與其它程式共享權限的程式。例如，能将一個随便的社交帳号和自己的大号(Fackbook或是Twitter)聯系起來。當通過服務登入Twitter(我們将這個過程Buffer)時，我們可以将這些Buffer附到Twitter的資料流上。
使用token時，可以提供可選的權限給第三方應用程式。當使用者想讓另一個應用程式通路它們的資料，我們可以通過建立自己的API，得出特殊權限的token。
（4）、多平台跨域
我們提前先來談論一下CORS(跨域資源共享)，對應用程式和服務進行擴充的時候，需要介入各種各種的裝置和應用程式。隻要使用者有一個通過了驗證的token，資料和資源就能夠在任何域上被請求到。
Access-Control-Allow-Origin: *
五、小結
本文旨在對Cookie、Session、Token做一些介紹說明，友善了解之用。Token的具體使用，可以參考另一篇博文 基于SpringBoot和Redis實作Token權限認證 。希望對大家有所幫助~