簡介
在Web領域基於Token的身份驗證隨處可見。在大多數使用Web API的互聯網公司中，tokens 是多用戶下處理認證的最佳方式。
以下幾點特性會讓你在程序中使用基於Token的身份驗證
1.無狀態、可擴展
2.支持移動設備
3.跨程序調用
4.安全
那些使用基於Token的身份驗證的大佬們
大部分你見到過的API和Web應用都使用tokens。例如Facebook, Twitter, Google+, GitHub等。
Token的起源
在介紹基於Token的身份驗證的原理與優勢之前，不妨先看看之前的認證都是怎麼做的。
基於服務器的驗證
我們都是知道HTTP協議是無狀態的，這種無狀態意味着程序需要驗證每一次請求，從而辨別客戶端的身份。
在這之前，程序都是通過在服務端存儲的登錄信息來辨別請求的。這種方式一般都是通過存儲Session來完成。
下圖展示了基於服務器驗證的原理
tokens-traditional
隨着Web，應用程序，已經移動端的興起，這種驗證的方式逐漸暴露出了問題。尤其是在可擴展性方面。
基於服務器驗證方式暴露的一些問題
1.Seesion：每次認證用戶發起請求時，服務器需要去創建一個記錄來存儲信息。當越來越多的用戶發請求時，內存的開銷也會不斷增加。
2.可擴展性：在服務端的內存中使用Seesion存儲登錄信息，伴隨而來的是可擴展性問題。
3.CORS(跨域資源共享)：當我們需要讓數據跨多臺移動設備上使用時，跨域資源的共享會是一個讓人頭疼的問題。在使用Ajax抓取另一個域的資源，就可以會出現禁止請求的情況。
4.CSRF(跨站請求僞造)：用戶在訪問銀行網站時，他們很容易受到跨站請求僞造的***，並且能夠被利用其訪問其他的網站。
在這些問題中，可擴展行是最突出的。因此我們有必要去尋求一種更有行之有效的方法。
基於Token的驗證原理
基於Token的身份驗證是無狀態的，我們不將用戶信息存在服務器或Session中。
這種概念解決了在服務端存儲信息時的許多問題
NoSession意味着你的程序可以根據需要去增減機器，而不用去擔心用戶是否登錄。
基於Token的身份驗證的過程如下:
1.用戶通過用戶名和密碼發送請求。
2.程序驗證。
3.程序返回一個簽名的token 給客戶端。
4.客戶端儲存token,並且每次用於每次發送請求。
5.服務端驗證token並返回數據。
每一次請求都需要token。token應該在HTTP的頭部發送從而保證了Http請求無狀態。我們同樣通過設置服務器屬性Access-Control-Allow-Origin: ，讓服務器能接受到來自所有域的請求。需要主要的是，在ACAO頭部標明(designating)時，不得帶有像HTTP認證，客戶端SSL證書和cookies的證書。