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

基于 Cookie/Session 的認(rèn)證方案

一、Cookie

• Cookie的工作原理

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

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

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

• Cookie的不可跨域名性

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

二、Session

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

如果說Cookie機(jī)制是通過檢查客戶身上的“通行證”來確定客戶身份的話，那么Session機(jī)制就是通過檢查服務(wù)器上的“客戶明細(xì)表”來確認(rèn)客戶身份。

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

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

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

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

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

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

2. cookie不是很安全，別人可以分析存放在本地的COOKIE并進(jìn)行 COOKIE欺騙，考慮到安全應(yīng)當(dāng)使用session；

3. session會在一定時(shí)間內(nèi)保存在服務(wù)器上。當(dāng)訪問增多，會比較占用你服務(wù)器的性能?？紤]到減輕服務(wù)器性能方面，應(yīng)當(dāng)使用COOKIE；

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

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

四、基于token的認(rèn)證方式

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

以下幾點(diǎn)特性會讓你在程序中使用基于Token的身份驗(yàn)證

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

2.支持移動(dòng)設(shè)備

3.跨程序調(diào)用

4.安全

五、Token的起源

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

• 基于服務(wù)器的驗(yàn)證

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

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

• 基于服務(wù)器驗(yàn)證方式暴露的一些問題

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

2.可擴(kuò)展性：在服務(wù)端的內(nèi)存中使用Seesion存儲登錄信息，伴隨而來的是可擴(kuò)展性問題。

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

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

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

六、基于Token的驗(yàn)證原理

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

七、基于Token的身份驗(yàn)證的過程如下:

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

2. 服務(wù)器端程序驗(yàn)證。

3. 3.服務(wù)器端程序返回一個(gè)帶簽名的token 給客戶端。

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

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

八、Tokens的優(yōu)勢

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

在客戶端存儲的Tokens是無狀態(tài)的，并且能夠被擴(kuò)展。基于這種無狀態(tài)和不存儲Session信息，負(fù)載負(fù)載均衡器能夠?qū)⒂脩粜畔囊粋€(gè)服務(wù)傳到其他服務(wù)器上。tokens自己hold住了用戶的驗(yàn)證信息。

• 安全性

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

token是有時(shí)效的，一段時(shí)間之后用戶需要重新驗(yàn)證。

• 可擴(kuò)展性

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

• 多平臺跨域

我們提前先來談?wù)撘幌翪ORS(跨域資源共享)，對應(yīng)用程序和服務(wù)進(jìn)行擴(kuò)展的時(shí)候，需要介入各種各種的設(shè)備和應(yīng)用程序。

九、需要設(shè)置有效期嗎？

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

那么有效期多長合適呢？

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

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

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

• 時(shí)序圖表示

使用 Token 和 Refresh Token 的時(shí)序圖如下：

1）登錄

2）業(yè)務(wù)請求

3）Token過期，刷新 Token

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

十、項(xiàng)目中使用token總結(jié)

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

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

2.后服務(wù)端收到請求，去驗(yàn)證用戶名與密碼是否正確

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

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

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

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

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

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

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