1.基于服務器的驗證

我們都是知道HTTP協議是無狀態的，這種無狀態意味著程序需要驗證每一次請求，從而辨別客戶端的身份。? 在這之前，程序都是通過在服務端存儲的登錄信息來辨別請求的。這種方式一般都是通過存儲Session來完成。

基于服務器驗證方式暴露的一些問題：

1.Seesion：每次認證用戶發起請求時，服務器需要去創建一個記錄來存儲信息。當越來越多的用戶發請求時，內存的開銷也會不斷增加。

2.可擴展性：在服務端的內存中使用Seesion存儲登錄信息，伴隨而來的是可擴展性問題。

3.CORS(跨域資源共享)：當我們需要讓數據跨多臺移動設備上使用時，跨域資源的共享會是一個讓人頭疼的問題。在使用Ajax抓取另一個域的資源，就可以會出現禁止請求的情況。

4.CSRF(跨站請求偽造)：用戶在訪問銀行網站時，他們很容易受到跨站請求偽造的攻擊，并且能夠被利用其訪問其他的網站。
在這些問題中，可擴展性是最突出的。因此我們有必要去尋求一種更有行之有效的方法。

2.基于Token的身份驗證

使用基于 Token 的身份驗證方法，在服務端不需要存儲用戶的登錄記錄。大概的流程是這樣的：?

1.客戶端使用用戶名跟密碼請求登錄?

2.服務端收到請求，去驗證用戶名與密碼驗證成功后，服務端會簽發一個 Token，再把這個 Token 發送給客戶端?

3.客戶端收到 Token 以后可以把它存儲起來，比如放在 Cookie 里或者 Local Storage 里客戶端每次向服務端請求資源的時候需要帶著服務端簽發的 Token服務端收到請求，然后去驗證客戶端請求里面帶著的 Token，如果驗證成功，就向客戶端返回請求的數據。

基于Token驗證的優勢：

1.無狀態、可擴展
在客戶端存儲的Token是無狀態的，并且能夠被擴展。基于這種無狀態和不存儲Session信息，負載均衡器能夠將用戶信息從一個服務傳到其他服務器上。如果我們將已驗證的用戶的信息保存在Session中，則每次請求都需要用戶向已驗證的服務器發送驗證信息(稱為Session親和性)。用戶量大時，可能會造成

一些擁堵。

2.安全性

請求中發送token而不再是發送cookie能夠防止CSRF(跨站請求偽造)。即使在客戶端使用cookie存儲token，cookie也僅僅是一個存儲機制而不是用于認證。不將信息存儲在Session中，讓我們少了對session操作。token是有時效的，一段時間之后用戶需要重新驗證。我們也不一定需要等到token自動失效，token有撤回的操作，通過token revocataion可以使一個特定的token或是一組有相同認證的token無效。

3.可擴展性
Tokens能夠創建與其它程序共享權限的程序。例如，能將一個隨便的社交帳號和自己的大號(Fackbook或是Twitter)聯系起來。當通過服務登錄Twitter(我們將這個過程Buffer)時，我們可以將這些Buffer附到Twitter的數據流上(we are allowing Buffer to post to our Twitter stream)。

使用tokens時，可以提供可選的權限給第三方應用程序。當用戶想讓另一個應用程序訪問它們的數據，我們可以通過建立自己的API，得出特殊權限的tokens。

4.多平臺跨域
我們提前先來談論一下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，數據和資源就能夠在任何域上被請求到。

Access-Control-Allow-Origin: *

5.基于標準

創建token的時候，你可以設定一些選項。我們在后續的文章中會進行更加詳盡的描述，但是標準的用法會在JSON Web Tokens體現。最近的程序和文檔是供給JSON Web Tokens的。它支持眾多的語言。這意味在未來的使用中你可以真正的轉換你的認證機制。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的基于Token进行身份验证的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。