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

Cookie

• Cookie的工作原理

由于HTTP是一種無(wú)狀態(tài)的協(xié)議，服務(wù)器單從網(wǎng)絡(luò)連接上無(wú)從知道客戶身份。怎么辦呢？就給客戶端們頒發(fā)一個(gè)通行證吧，每人一個(gè)，無(wú)論誰(shuí)訪問都必須攜帶自己通行證。這樣服務(wù)器就能從通行證上確認(rèn)客戶身份了。這就是。cookie指的就是在瀏覽器里面存儲(chǔ)的一種數(shù)據(jù)，僅僅是瀏覽器實(shí)現(xiàn)的一種數(shù)據(jù)存儲(chǔ)功能。cookie的保存時(shí)間，可以自己在程序中設(shè)置。如果沒有設(shè)置保存時(shí)間，應(yīng)該是一關(guān)閉瀏覽器，cookie就自動(dòng)消失。

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

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

• Cookie的不可跨域名性

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

Session

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

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

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

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

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

提示：Session的使用比Cookie方便，但是過多的Session存儲(chǔ)在服務(wù)器內(nèi)存中，會(huì)對(duì)服務(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會(huì)在一定時(shí)間內(nèi)保存在服務(wù)器上。當(dāng)訪問增多，會(huì)比較占用你服務(wù)器的性能?？紤]到減輕服務(wù)器性能方面，應(yīng)當(dāng)使用COOKIE；
4. 單個(gè)cookie在客戶端的限制是3K，就是說一個(gè)站點(diǎn)在客戶端存放的COOKIE不能超過3K；

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

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

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

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

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

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

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

4.安全

Token的起源

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 用戶通過用戶名和密碼發(fā)送請(qǐng)求。
2. 服務(wù)器端程序驗(yàn)證。

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

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

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

Tokens的優(yōu)勢(shì)

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

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

• 安全性

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

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

• 可擴(kuò)展性

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

• 多平臺(tái)跨域

我們提前先來(lái)談?wù)撘幌?code style="font-size: 14px;border-radius: 4px;font-family: Operator Mono, Consolas, Monaco, Menlo, monospace;word-break: break-all;color: rgb(155, 110, 35);background-color: rgb(255, 245, 227);padding: 3px;margin: 3px;">CORS(跨域資源共享)，對(duì)應(yīng)用程序和服務(wù)進(jìn)行擴(kuò)展的時(shí)候，需要介入各種各種的設(shè)備和應(yīng)用程序。

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

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

• 那么有效期多長(zhǎng)合適呢？

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

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

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

• 時(shí)序圖表示

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

1）登錄

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

3）Token過期，刷新 Token

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

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

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

1.前端使用用戶名跟密碼請(qǐng)求首次登錄

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

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

4.前端收到 返回的Token ，把它存儲(chǔ)起來(lái)，比如放在 Cookie 里或者 Local Storage 里

5.前端每次路由跳轉(zhuǎn)，判斷 localStroage 有無(wú) token ，沒有則跳轉(zhuǎn)到登錄頁(yè)。有則請(qǐng)求獲取用戶信息，改變登錄狀態(tài)；6.前端每次向服務(wù)端請(qǐng)求資源的時(shí)候需要在請(qǐng)求頭里攜帶服務(wù)端簽發(fā)的Token

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

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