由于HTTP是一種無狀態(tài)的協(xié)議，服務器單從網(wǎng)絡連接上無從知道客戶身份。怎么辦呢？就給客戶端們頒發(fā)一個通行證吧，每人一個，無論誰訪問都必須攜帶自己通行證。這樣服務器就能從通行證上確認客戶身份了。

基于 Cookie/Session 的認證方案

一、Cookie

• Cookie的工作原理

cookie指的就是在瀏覽器里面存儲的一種數(shù)據(jù)，僅僅是瀏覽器實現(xiàn)的一種數(shù)據(jù)存儲功能。cookie的保存時間，可以自己在程序中設置。如果沒有設置保存時間，應該是一關閉瀏覽器，cookie就自動消失。

Cookie實際上是一小段的文本信息。客戶端請求服務器，如果服務器需要記錄該用戶狀態(tài)，就使用response向客戶端瀏覽器頒發(fā)一個Cookie。客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網(wǎng)站時，瀏覽器把請求的網(wǎng)址連同該Cookie一同提交給服務器。服務器檢查該Cookie，以此來辨認用戶狀態(tài)。服務器還可以根據(jù)需要修改Cookie的內容。

注意：Cookie功能需要瀏覽器的支持。如果瀏覽器不支持Cookie（如大部分手機中的瀏覽器）或者把Cookie禁用了，Cookie功能就會失效。不同的瀏覽器采用不同的方式保存Cookie。IE瀏覽器會以文本文件形式保存，一個文本文件保存一個Cookie。

• Cookie的不可跨域名性

Cookie具有不可跨域名性。根據(jù)Cookie規(guī)范，瀏覽器訪問Google只會攜帶Google的Cookie，而不會攜帶Baidu的Cookie。瀏覽器判斷一個網(wǎng)站是否能操作另一個網(wǎng)站Cookie的依據(jù)是域名。

二、Session

Session是另一種記錄客戶狀態(tài)的機制，不同的是Cookie保存在客戶端瀏覽器中，而Session保存在服務器上?？蛻舳藶g覽器訪問服務器的時候，服務器把客戶端信息以某種形式記錄在服務器上。這就是Session?？蛻舳藶g覽器再次訪問時只需要從該Session中查找該客戶的狀態(tài)就可以了。

如果說Cookie機制是通過檢查客戶身上的“通行證”來確定客戶身份的話，那么Session機制就是通過檢查服務器上的“客戶明細表”來確認客戶身份。

session 也是類似的道理，服務器要知道當前發(fā)請求給自己的是誰。為了做這種區(qū)分，服務器就要給每個客戶端分配不同的“身份標識”，然后客戶端每次向服務器發(fā)請求的時候，都帶上這個“身份標識”，服務器就知道這個請求來自于誰了。對于瀏覽器客戶端，大家都默認采用 cookie 的方式，保存這個“身份標識”。

服務器使用session把用戶的信息臨時保存在了服務器上，用戶離開網(wǎng)站后session會被銷毀。這種用戶信息存儲方式相對cookie來說更安。

可是session有一個缺陷：如果web服務器做了負載均衡，那么下一個操作請求到了另一臺服務器的時候session會丟失。

提示：Session的使用比Cookie方便，但是過多的Session存儲在服務器內存中，會對服務器造成壓力。

三、Cookie與Session的區(qū)別和聯(lián)系

1. cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務器上；

2. cookie不是很安全，別人可以分析存放在本地的COOKIE并進行 COOKIE欺騙，考慮到安全應當使用session；

3. session會在一定時間內保存在服務器上。當訪問增多，會比較占用你服務器的性能?？紤]到減輕服務器性能方面，應當使用COOKIE；

4. 單個cookie在客戶端的限制是3K，就是說一個站點在客戶端存放的COOKIE不能超過3K；

Cookie和Session的方案雖然分別屬于客戶端和服務端，但是服務端的session的實現(xiàn)對客戶端的cookie有依賴關系的，上面我講到服務端執(zhí)行session機制時候會生成session的id值，這個id值會發(fā)送給客戶端，客戶端每次請求都會把這個id值放到http請求的頭部發(fā)送給服務端，而這個id值在客戶端會保存下來，保存的容器就是cookie，因此當我們完全禁掉瀏覽器的cookie的時候，服務端的session也會不能正常使用。

四、基于token的認證方式

在大多數(shù)使用Web API的互聯(lián)網(wǎng)公司中，tokens 是多用戶下處理認證的最佳方式。

以下幾點特性會讓你在程序中使用基于Token的身份驗證

1.無狀態(tài)、可擴展

2.支持移動設備

3.跨程序調用

4.安全

五、Token的起源

在介紹基于Token的身份驗證的原理與優(yōu)勢之前，不妨先看看之前的認證都是怎么做的。

• 基于服務器的驗證

我們都是知道HTTP協(xié)議是無狀態(tài)的，這種無狀態(tài)意味著程序需要驗證每一次請求，從而辨別客戶端的身份。

在這之前，程序都是通過在服務端存儲的登錄信息來辨別請求的。這種方式一般都是通過存儲Session來完成。

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

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

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

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

4.CSRF(跨站請求偽造)：用戶在訪問銀行網(wǎng)站時，他們很容易受到跨站請求偽造的攻擊，并且能夠被利用其訪問其他的網(wǎng)站。

在這些問題中，可擴展行是最突出的。因此我們有必要去尋求一種更有行之有效的方法。

六、基于Token的驗證原理

基于Token的身份驗證是無狀態(tài)的，我們不將用戶信息存在服務器中。這種概念解決了在服務端存儲信息時的許多問題。NoSession意味著你的程序可以根據(jù)需要去增減機器，而不用去擔心用戶是否登錄。

七、基于Token的身份驗證的過程如下:

1. 用戶通過用戶名和密碼發(fā)送請求。

2. 服務器端程序驗證。

3. 3.服務器端程序返回一個帶簽名的token 給客戶端。

4. 4.客戶端儲存token,并且每次訪問API都攜帶Token到服務器端的。

5. 5.服務端驗證token，校驗成功則返回請求數(shù)據(jù)，校驗失敗則返回錯誤碼。

八、Tokens的優(yōu)勢

• 無狀態(tài)、可擴展

在客戶端存儲的Tokens是無狀態(tài)的，并且能夠被擴展?；谶@種無狀態(tài)和不存儲Session信息，負載負載均衡器能夠將用戶信息從一個服務傳到其他服務器上。tokens自己hold住了用戶的驗證信息。

• 安全性

請求中發(fā)送token而不再是發(fā)送cookie能夠防止CSRF(跨站請求偽造)。即使在客戶端使用cookie存儲token，cookie也僅僅是一個存儲機制而不是用于認證。不將信息存儲在Session中，讓我們少了對session操作。

token是有時效的，一段時間之后用戶需要重新驗證。

• 可擴展性

Tokens能夠創(chuàng)建與其它程序共享權限的程序。

• 多平臺跨域

我們提前先來談論一下CORS(跨域資源共享)，對應用程序和服務進行擴展的時候，需要介入各種各種的設備和應用程序。

九、需要設置有效期嗎？

對于這個問題，我們不妨先看兩個例子。一個例子是登錄密碼，一般要求定期改變密碼，以防止泄漏，所以密碼是有有效期的；另一個例子是安全證書。SSL 安全證書都有有效期，目的是為了解決吊銷的問題。所以無論是從安全的角度考慮，還是從吊銷的角度考慮，Token 都需要設有效期。

那么有效期多長合適呢？

只能說，根據(jù)系統(tǒng)的安全需要，盡可能的短，但也不能短得離譜

• 然后新問題產生了，如果用戶在正常操作的過程中，Token 過期失效了，要求用戶重新登錄……用戶體驗豈不是很糟糕？

一種方案，使用 Refresh Token，它可以避免頻繁的讀寫操作。這種方案中，服務端不需要刷新 Token 的過期時間，一旦 Token 過期，就反饋給前端，前端使用 Refresh Token 申請一個全新Token 繼續(xù)使用。這種方案中，服務端只需要在客戶端請求更新 Token 的時候對 Refresh Token 的有效性進行一次檢查，大大減少了更新有效期的操作，也就避免了頻繁讀寫。當然 Refresh Token 也是有有效期的，但是這個有效期就可以長一點了，比如，以天為單位的時間。

• 時序圖表示

使用 Token 和 Refresh Token 的時序圖如下：

1）登錄

2）業(yè)務請求

3）Token過期，刷新 Token

上面的時序圖中并未提到 Refresh Token 過期怎么辦。不過很顯然，Refresh Token 既然已經過期，就該要求用戶重新登錄了。

十、項目中使用token總結

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

1.前端使用用戶名跟密碼請求首次登錄

2.后服務端收到請求，去驗證用戶名與密碼是否正確

3.驗證成功后，服務端會根據(jù)用戶id、用戶名、定義好的秘鑰、過期時間生成一個 Token，再把這個 Token 發(fā)送給前端

4.前端收到 返回的Token ，把它存儲起來，比如放在 Cookie 里或者 Local Storage 里

5.前端每次路由跳轉，判斷 localStroage 有無 token ，沒有則跳轉到登錄頁。有則請求獲取用戶信息，改變登錄狀態(tài)；

6.前端每次向服務端請求資源的時候需要在請求頭里攜帶服務端簽發(fā)的Token

7.服務端收到請求，然后去驗證前端請求里面帶著的 Token。沒有或者 token 過期，返回401。如果驗證成功，就向前端返回請求的數(shù)據(jù)。

8.前端得到 401 狀態(tài)碼，重定向到登錄頁面。

本文鏈接：http://www.azlx8.cn/article/1087.html