前端登錄，這一篇就夠了

作者：佚名 2020-08-03 10:00:11

登錄是每個網站中都經常用到的一個功能，在頁面上我們輸入賬號密碼，敲一下回車鍵，就登錄了，但這背后的登錄原理你是否清楚呢？今天我們就來介紹幾種常用的登錄方式。

Cookie + Session 登錄
Token 登錄
SSO 單點登錄
OAuth 第三方登錄

Cookie + Session 登錄

HTTP 是一種無狀態的協議，客戶端每次發送請求時，首先要和服務器端建立一個連接，在請求完成后又會斷開這個連接。這種方式可以節省傳輸時占用的連接資源，但同時也存在一個問題：每次請求都是獨立的，服務器端無法判斷本次請求和上一次請求是否來自同一個用戶，進而也就無法判斷用戶的登錄狀態。

為了解決 HTTP 無狀態的問題，Lou Montulli 在 1994 年的時候，推出了 Cookie。

Cookie 是服務器端發送給客戶端的一段特殊信息，這些信息以文本的方式存放在客戶端，客戶端每次向服務器端發送請求時都會帶上這些特殊信息。

有了 Cookie 之后，服務器端就能夠獲取到客戶端傳遞過來的信息了，如果需要對信息進行驗證，還需要通過 Session。

客戶端請求服務端，服務端會為這次請求開辟一塊內存空間，這個便是 Session 對象。

有了 Cookie 和 Session 之后，我們就可以進行登錄認證了。

Cookie + Session 實現流程

Cookie + Session 的登錄方式是最經典的一種登錄方式，現在仍然有大量的企業在使用。

用戶首次登錄時：

用戶訪問 a.com/pageA，并輸入密碼登錄。
服務器驗證密碼無誤后，會創建 SessionId，并將它保存起來。
服務器端響應這個 HTTP 請求，并通過 Set-Cookie 頭信息，將 SessionId 寫入 Cookie 中。

服務器端的 SessionId 可能存放在很多地方，例如：內存、文件、數據庫等。

第一次登錄完成之后，后續的訪問就可以直接使用 Cookie 進行身份驗證了：

用戶訪問 a.com/pageB 頁面時，會自動帶上第一次登錄時寫入的 Cookie。
服務器端比對 Cookie 中的 SessionId 和保存在服務器端的 SessionId 是否一致。
如果一致，則身份驗證成功。

Cookie + Session 存在的問題

雖然我們使用 Cookie + Session 的方式完成了登錄驗證，但仍然存在一些問題：

由于服務器端需要對接大量的客戶端，也就需要存放大量的 SessionId，這樣會導致服務器壓力過大。
如果服務器端是一個集群，為了同步登錄態，需要將 SessionId 同步到每一臺機器上，無形中增加了服務器端維護成本。
由于 SessionId 存放在 Cookie 中，所以無法避免 CSRF 攻擊。

Token 登錄

為了解決 Session + Cookie 機制暴露出的諸多問題，我們可以使用 Token 的登錄方式。

Token 是服務端生成的一串字符串，以作為客戶端請求的一個令牌。當第一次登錄后，服務器會生成一個 Token 并返回給客戶端，客戶端后續訪問時，只需帶上這個 Token 即可完成身份認證。

Token 機制實現流程

用戶首次登錄時：

用戶輸入賬號密碼，并點擊登錄。
服務器端驗證賬號密碼無誤，創建 Token。
服務器端將 Token 返回給客戶端，由***客戶端自由保存***。

后續頁面訪問時：

用戶訪問 a.com/pageB 時，帶上第一次登錄時獲取的 Token。
服務器端驗證 Token ，有效則身份驗證成功。

Token 機制的特點

根據上面的案例，我們可以分析出 Token 的優缺點：

服務器端不需要存放 Token，所以不會對服務器端造成壓力，即使是服務器集群，也不需要增加維護成本。
Token 可以存放在前端任何地方，可以不用保存在 Cookie 中，提升了頁面的安全性。
Token 下發之后，只要在生效時間之內，就一直有效，如果服務器端想收回此 Token 的權限，并不容易。

Token 的生成方式

最常見的 Token 生成方式是使用 JWT（Json Web Token），它是一種簡潔的，自包含的方法用于通信雙方之間以 JSON 對象的形式安全的傳遞信息。

上文中我們說到，使用 Token 后，服務器端并不會存儲 Token，那怎么判斷客戶端發過來的 Token 是合法有效的呢？

答案其實就在 Token 字符串中，其實 Token 并不是一串雜亂無章的字符串，而是通過多種算法拼接組合而成的字符串，我們來具體分析一下。

JWT 算法主要分為 3 個部分：header（頭信息），playload（消息體），signature（簽名）。

header 部分指定了該 JWT 使用的簽名算法:

header = '{"alg":"HS256","typ":"JWT"}'   // `HS256` 表示使用了 HMAC-SHA256 來生成簽名。

playload 部分表明了 JWT 的意圖：

payload = '{"loggedInAs":"admin","iat":1422779638}'     //iat 表示令牌生成的時間

signature 部分為 JWT 的簽名，主要為了讓 JWT 不能被隨意篡改，簽名的方法分為兩個步驟：

輸入 base64url 編碼的 header 部分、 . 、base64url 編碼的 playload 部分，輸出 unsignedToken。
輸入服務器端私鑰、unsignedToken，輸出 signature 簽名。

const base64Header = encodeBase64(header)  
const base64Payload = encodeBase64(payload) 
const unsignedToken = `${base64Header}.${base64Payload}`  
const key = '服務器私鑰'  
signature = HMAC(key, unsignedToken)

最后的 Token 計算如下：

const base64Header = encodeBase64(header)  
const base64Payload = encodeBase64(payload)  
const base64Signature = encodeBase64(signature)  
token = `${base64Header}.${base64Payload}.${base64Signature}`

服務器在判斷 Token 時：

const [base64Header, base64Payload, base64Signature] = token.split('.')  
const signature1 = decodeBase64(base64Signature)  
const unsignedToken = `${base64Header}.${base64Payload}`  
const signature2 = HMAC('服務器私鑰', unsignedToken)  
if(signature1 === signature2) {  
  return '簽名驗證成功，token 沒有被篡改'  
}  
const payload =  decodeBase64(base64Payload)  
if(new Date() - payload.iat < 'token 有效期'){  
  return 'token 有效'  
}