前端應該學習的Token登錄認證知識
前程序員成長指北」作者：chrisghb
來源：https://www.jianshu.com/p/a32634a5170c
基于 Cookie/Session 的認證方案
Cookie
Cookie的工作原理
由于HTTP是一種無狀態(tài)的協(xié)議，服務器單從網(wǎng)絡連接上無從知道客戶身份。怎么辦呢？就給客戶端們頒發(fā)一個通行證吧，每人一個，無論誰訪問都必須攜帶自己通行證。這樣服務器就能從通行證上確認客戶身份了。這就是。cookie指的就是在瀏覽器里面存儲的一種數(shù)據(jù)，僅僅是瀏覽器實現(xiàn)的一種數(shù)據(jù)存儲功能。cookie的保存時間，可以自己在程序中設置。如果沒有設置保存時間，應該是一關閉瀏覽器，cookie就自動消失。
Cookie實際上是一小段的文本信息?？蛻舳苏埱蠓掌鳎绻掌餍枰涗浽撚脩魻顟B(tài)，就使用response向客戶端瀏覽器頒發(fā)一個Cookie?？蛻舳藶g覽器會把Cookie保存起來。當瀏覽器再請求該網(wǎng)站時，瀏覽器把請求的網(wǎng)址連同該Cookie一同提交給服務器。服務器檢查該Cookie，以此來辨認用戶狀態(tài)。服務器還可以根據(jù)需要修改Cookie的內(nèi)容。
注意：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保存在服務器上。客戶端瀏覽器訪問服務器的時候，服務器把客戶端信息以某種形式記錄在服務器上。這就是Session。客戶端瀏覽器再次訪問時只需要從該Session中查找該客戶的狀態(tài)就可以了。
如果說Cookie機制是通過檢查客戶身上的“通行證”來確定客戶身份的話，那么Session機制就是通過檢查服務器上的“客戶明細表”來確認客戶身份。
session 也是類似的道理，服務器要知道當前發(fā)請求給自己的是誰。為了做這種區(qū)分，服務器就要給每個客戶端分配不同的“身份標識”，然后客戶端每次向服務器發(fā)請求的時候，都帶上這個“身份標識”，服務器就知道這個請求來自于誰了。對于瀏覽器客戶端，大家都默認采用 cookie 的方式，保存這個“身份標識”。
服務器使用session把用戶的信息臨時保存在了服務器上，用戶離開網(wǎng)站后session會被銷毀。這種用戶信息存儲方式相對cookie來說更安。
可是session有一個缺陷：如果web服務器做了負載均衡，那么下一個操作請求到了另一臺服務器的時候session會丟失。
提示：Session的使用比Cookie方便，但是過多的Session存儲在服務器內(nèi)存中，會對服務器造成壓力。
Cookie與Session的區(qū)別和聯(lián)系
cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務器上；cookie不是很安全，別人可以分析存放在本地的COOKIE并進行COOKIE欺騙，考慮到安全應當使用session；session會在一定時間內(nèi)保存在服務器上。當訪問增多，會比較占用你服務器的性能。考慮到減輕服務器性能方面，應當使用COOKIE；單個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.跨程序調(diào)用
4.安全
Token的起源
在介紹基于Token的身份驗證的原理與優(yōu)勢之前，不妨先看看之前的認證都是怎么做的。
基于服務器的驗證
我們都是知道HTTP協(xié)議是無狀態(tài)的，這種無狀態(tài)意味著程序需要驗證每一次請求，從而辨別客戶端的身份。
在這之前，程序都是通過在服務端存儲的登錄信息來辨別請求的。這種方式一般都是通過存儲Session來完成。
基于服務器驗證方式暴露的一些問題
1.Seesion：每次認證用戶發(fā)起請求時，服務器需要去創(chuàng)建一個記錄來存儲信息。當越來越多的用戶發(fā)請求時，內(nèi)存的開銷也會不斷增加。
2.可擴展性：在服務端的內(nèi)存中使用Seesion存儲登錄信息，伴隨而來的是可擴展性問題。
3.CORS(跨域資源共享)：當我們需要讓數(shù)據(jù)跨多臺移動設備上使用時，跨域資源的共享會是一個讓人頭疼的問題。在使用Ajax抓取另一個域的資源，就可以會出現(xiàn)禁止請求的情況。
4.CSRF(跨站請求偽造)：用戶在訪問銀行網(wǎng)站時，他們很容易受到跨站請求偽造的攻擊，并且能夠被利用其訪問其他的網(wǎng)站。
在這些問題中，可擴展行是最突出的。因此我們有必要去尋求一種更有行之有效的方法。
基于Token的驗證原理
基于Token的身份驗證是無狀態(tài)的，我們不將用戶信息存在服務器中。這種概念解決了在服務端存儲信息時的許多問題。NoSession意味著你的程序可以根據(jù)需要去增減機器，而不用去擔心用戶是否登錄。
基于Token的身份驗證的過程如下:
用戶通過用戶名和密碼發(fā)送請求。 服務器端程序驗證。
3.服務器端程序返回一個帶簽名的token 給客戶端。
4.客戶端儲存token,并且每次訪問API都攜帶Token到服務器端的。
5.服務端驗證token，校驗成功則返回請求數(shù)據(jù)，校驗失敗則返回錯誤碼。
Tokens的優(yōu)勢
無狀態(tài)、可擴展
在客戶端存儲的Tokens是無狀態(tài)的，并且能夠被擴展?；谶@種無狀態(tài)和不存儲Session信息，負載負載均衡器能夠?qū)⒂脩粜畔囊粋€服務傳到其他服務器上。tokens自己hold住了用戶的驗證信息。
安全性
請求中發(fā)送token而不再是發(fā)送cookie能夠防止CSRF(跨站請求偽造)。即使在客戶端使用cookie存儲token，cookie也僅僅是一個存儲機制而不是用于認證。不將信息存儲在Session中，讓我們少了對session操作。
token是有時效的，一段時間之后用戶需要重新驗證。
可擴展性
Tokens能夠創(chuàng)建與其它程序共享權限的程序。
多平臺跨域
我們提前先來談論一下CORS(跨域資源共享)，對應用程序和服務進行擴展的時候，需要介入各種各種的設備和應用程序。
需要設置有效期嗎？
對于這個問題，我們不妨先看兩個例子。一個例子是登錄密碼，一般要求定期改變密碼，以防止泄漏，所以密碼是有有效期的；另一個例子是安全證書。SSL 安全證書都有有效期，目的是為了解決吊銷的問題。所以無論是從安全的角度考慮，還是從吊銷的角度考慮，Token 都需要設有效期。
那么有效期多長合適呢？
只能說，根據(jù)系統(tǒng)的安全需要，盡可能的短，但也不能短得離譜
然后新問題產(chǎn)生了，如果用戶在正常操作的過程中， Token過期失效了，要求用戶重新登錄……用戶體驗豈不是很糟糕？
一種方案，使用 Refresh Token，它可以避免頻繁的讀寫操作。這種方案中，服務端不需要刷新 Token 的過期時間，一旦 Token 過期，就反饋給前端，前端使用 Refresh Token 申請一個全新Token 繼續(xù)使用。這種方案中，服務端只需要在客戶端請求更新 Token 的時候?qū)?Refresh Token 的有效性進行一次檢查，大大減少了更新有效期的操作，也就避免了頻繁讀寫。當然 Refresh Token 也是有有效期的，但是這個有效期就可以長一點了，比如，以天為單位的時間。
時序圖表示
使用 Token 和 Refresh Token 的時序圖如下：
1）登錄
2）業(yè)務請求
3）Token過期，刷新 Token
上面的時序圖中并未提到 Refresh Token 過期怎么辦。不過很顯然，Refresh Token 既然已經(jīng)過期，就該要求用戶重新登錄了。
項目中使用token總結(jié)
使用基于 Token 的身份驗證方法，在服務端不需要存儲用戶的登錄記錄。大概的流程是這樣的：
1.前端使用用戶名跟密碼請求首次登錄
2.后服務端收到請求，去驗證用戶名與密碼是否正確
3.驗證成功后，服務端會根據(jù)用戶id、用戶名、定義好的秘鑰、過期時間生成一個 Token，再把這個 Token 發(fā)送給前端
4.前端收到 返回的Token ，把它存儲起來，比如放在 Cookie 里或者 Local Storage 里
export interface User {
token: string;
userInfo: UserInfo | any;
companyInfo: CompanyInfo | any;
resources?: string[];
}
save(key: string, value: any, storageType ?: StorageType) {
return this.storageService.put(
{
pool: key,
key: 'chris-app',
storageType: StorageType.localStorage
},
value
);
}
this.storageService.save(CACHE_USER_KEY, user);
5.前端每次路由跳轉(zhuǎn)，判斷 localStroage 有無 token ，沒有則跳轉(zhuǎn)到登錄頁。有則請求獲取用戶信息，改變登錄狀態(tài)；6.前端每次向服務端請求資源的時候需要在請求頭里攜帶服務端簽發(fā)的Token
HttpInterceptor => headers = headers.set('token', this.authService.getToken());
7.服務端收到請求，然后去驗證前端請求里面帶著的 Token。沒有或者 token 過期，返回401。如果驗證成功，就向前端返回請求的數(shù)據(jù)。
8.前端得到 401 狀態(tài)碼，重定向到登錄頁面。
HttpInterceptor =>
401: '用戶登陸狀態(tài)失效，請重新登陸。'
1.看到這里了就點個在看支持下吧，你的「點贊，在看」是我創(chuàng)作的動力。
2.關注公眾號
程序員成長指北，回復「1」加入高級前端交流群！「在這里有好多 前端 開發(fā)者，會討論 前端 Node 知識，互相學習」！3.也可添加微信【ikoala520】，一起成長。
“在看轉(zhuǎn)發(fā)”是最大的支持