Cokkie
? ? ? ? cookie 是一個非常具體的東西，指的就是瀏覽器里面能永久存儲的一種數(shù)據(jù)，僅僅是瀏覽器實現(xiàn)的一種數(shù)據(jù)存儲功能。cookie由服務器生成，發(fā)送給瀏覽器，瀏覽器把cookie以kv形式保存到某個目錄下的文本文件內(nèi)，下一次請求同一網(wǎng)站時會把該cookie發(fā)送給服務器。由于cookie是存在客戶端上的，所以瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會占據(jù)太多磁盤空間，所以每個域的cookie數(shù)量是有限的。
Session
session 從字面上講，就是會話。這個就類似于你和一個人交談，你怎么知道當前和你交談的是張三而不是李四呢？對方肯定有某種特征（長相等）表明他就是張三。
session 也是類似的道理，服務器要知道當前發(fā)請求給自己的是誰。為了做這種區(qū)分，服務器就要給每個客戶端分配不同的“身份標識”，然后客戶端每次向服務器發(fā)請求的時候，都帶上這個“身份標識”，服務器就知道這個請求來自于誰了。至于客戶端怎么保存這個“身份標識”，可以有很多種方式，對于瀏覽器客戶端，大家都默認采用 cookie 的方式。
服務器使用session把用戶的信息臨時保存在了服務器上，用戶離開網(wǎng)站后session會被銷毀。這種用戶信息存儲方式相對cookie來說更安全，可是session有一個缺陷：如果web服務器做了負載均衡，那么下一個操作請求到了另一臺服務器的時候session會丟失。
Token
在Web領(lǐng)域基于Token的身份驗證隨處可見。在大多數(shù)使用Web API的互聯(lián)網(wǎng)公司中，tokens 是多用戶下處理認證的最佳方式。
以下幾點特性會讓你在程序中使用基于Token的身份驗證
1.無狀態(tài)、可擴展
2.支持移動設備
3.跨程序調(diào)用
4.安全
那些使用基于Token的身份驗證的大佬們大部分你見到過的API和Web應用都使用tokens。例如Facebook, Twitter, Google+, GitHub等。
基于Token的驗證原理
基于Token的身份驗證是無狀態(tài)的，我們不將用戶信息存在服務器或Session中。這種概念解決了在服務端存儲信息時的許多問題。
NoSession意味著你的程序可以根據(jù)需要去增減機器，而不用去擔心用戶是否登錄。
基于Token的身份驗證的過程如下:
用戶通過用戶名和密碼發(fā)送請求。
程序驗證。
程序返回一個簽名的token 給客戶端。
客戶端儲存token,并且每次用于每次發(fā)送請求。
服務端驗證token并返回數(shù)據(jù)。
每一次請求都需要token。token應該在HTTP的頭部發(fā)送從而保證了Http請求無狀態(tài)。我們同樣通過設置服務器屬性Access-Control-Allow-Origin:* ，讓服務器能接受到來自所有域的請求。
需要主要的是，在ACAO頭部標明(designating)*時，不得帶有像HTTP認證，客戶端SSL證書和cookies的證書。
實現(xiàn)思路：
1.用戶登錄校驗，校驗成功后就返回Token給客戶端。
2.客戶端收到數(shù)據(jù)后保存在客戶端
3.客戶端每次訪問API是攜帶Token到服務器端。
4.服務器端采用filter過濾器校驗。校驗成功則返回請求數(shù)據(jù)，校驗失敗則返回錯誤碼
當我們在程序中認證了信息并取得token之后，我們便能通過這個Token做許多的事情。
我們甚至能基于創(chuàng)建一個基于權(quán)限的token傳給第三方應用程序，這些第三方程序能夠獲取到我們的數(shù)據(jù)（當然只有在我們允許的特定的token）
Token的優(yōu)勢
無狀態(tài)、可擴展
在客戶端存儲的Tokens是無狀態(tài)的，并且能夠被擴展?；谶@種無狀態(tài)和不存儲Session信息，負載負載均衡器能夠?qū)⒂脩粜畔囊粋€服務傳到其他服務器上。
如果我們將已驗證的用戶的信息保存在Session中，則每次請求都需要用戶向已驗證的服務器發(fā)送驗證信息(稱為Session親和性)。用戶量大時，可能會造成一些擁堵。
但是不要著急。使用tokens之后這些問題都迎刃而解，因為tokens自己hold住了用戶的驗證信息。
安全性
請求中發(fā)送token而不再是發(fā)送cookie能夠防止CSRF(跨站請求偽造)。即使在客戶端使用cookie存儲token，cookie也僅僅是一個存儲機制而不是用于認證。不將信息存儲在Session中，讓我們少了對session操作。
token是有時效的，一段時間之后用戶需要重新驗證。我們也不一定需要等到token自動失效，token有撤回的操作，通過token revocataion可以使一個特定的token或是一組有相同認證的token無效。
可擴展性
Tokens能夠創(chuàng)建與其它程序共享權(quán)限的程序。例如，能將一個隨便的社交帳號和自己的大號(Fackbook或是Twitter)聯(lián)系起來。當通過服務登錄Twitter(我們將這個過程Buffer)時，我們可以將這些Buffer附到Twitter的數(shù)據(jù)流上(we are allowing Buffer to post to our Twitter stream)。
使用tokens時，可以提供可選的權(quán)限給第三方應用程序。當用戶想讓另一個應用程序訪問它們的數(shù)據(jù)，我們可以通過建立自己的API，得出特殊權(quán)限的tokens。
多平臺跨域
我們提前先來談論一下CORS(跨域資源共享)，對應用程序和服務進行擴展的時候，需要介入各種各種的設備和應用程序。
Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.
只要用戶有一個通過了驗證的token，數(shù)據(jù)和資源就能夠在任何域上被請求到。
Access-Control-Allow-Origin:?*
基于標準創(chuàng)建token的時候，你可以設定一些選項。我們在后續(xù)的文章中會進行更加詳盡的描述，但是標準的用法會在JSON Web Tokens體現(xiàn)。
最近的程序和文檔是供給JSON Web Tokens的。它支持眾多的語言。這意味在未來的使用中你可以真正的轉(zhuǎn)換你的認證機制。
