前端登錄，這一篇就夠了
登錄是每個網站中都經常用到的一個功能，在頁面上我們輸入賬號密碼，敲一下回車鍵，就登錄了，但這背后的登錄原理你是否清楚呢？今天我們就來介紹幾種常用的登錄方式。
- 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 有效'
- }
有了 Token 之后，登錄方式已經變得非常高效，接下來我們介紹另外兩種登錄方式。
SSO 單點登錄
單點登錄指的是在公司內部搭建一個公共的認證中心，公司下的所有產品的登錄都可以在認證中心里完成，一個產品在認證中心登錄后，再去訪問另一個產品，可以不用再次登錄，即可獲取登錄狀態。
SSO 機制實現流程
用戶首次訪問時，需要在認證中心登錄：
- 用戶訪問網站 a.com 下的 pageA 頁面。
- 由于沒有登錄，則會重定向到認證中心，并帶上回調地址 www.sso.com?return_uri=a.com/pageA，以便登錄后直接進入對應頁面。
- 用戶在認證中心輸入賬號密碼，提交登錄。
- 認證中心驗證賬號密碼有效，然后重定向 a.com?ticket=123 帶上授權碼 ticket，并將認證中心 sso.com 的登錄態寫入 Cookie。
- 在 a.com 服務器中，拿著 ticket 向認證中心確認，授權碼 ticket 真實有效。
- 驗證成功后，服務器將登錄信息寫入 Cookie（此時客戶端有 2 個 Cookie 分別存有 a.com 和 sso.com 的登錄態）。
認證中心登錄完成之后，繼續訪問 a.com 下的其他頁面：
這個時候，由于 a.com 存在已登錄的 Cookie 信息，所以服務器端直接認證成功。
如果認證中心登錄完成之后，訪問 b.com 下的頁面：
這個時候，由于認證中心存在之前登錄過的 Cookie，所以也不用再次輸入賬號密碼，直接返回第 4 步，下發 ticket 給 b.com 即可。
SSO 單點登錄退出
目前我們已經完成了單點登錄，在同一套認證中心的管理下，多個產品可以共享登錄態。現在我們需要考慮退出了，即：在一個產品中退出了登錄，怎么讓其他的產品也都退出登錄？
原理其實不難，可以回過頭來看第 5 步，每一個產品在向認證中心驗證 ticket 時，其實可以順帶將自己的退出登錄 api 發送到認證中心。
當某個產品 c.com 退出登錄時：
- 清空 c.com 中的登錄態 Cookie。
- 請求認證中心 sso.com 中的退出 api。
- 認證中心遍歷下發過 ticket 的所有產品，并調用對應的退出 api，完成退出。
OAuth 第三方登錄
在上文中，我們使用單點登錄完成了多產品的登錄態共享，但都是建立在一套統一的認證中心下，對于一些小型企業，未免太麻煩，有沒有一種登錄能夠做到開箱即用？
其實是有的，很多大廠都會提供自己的第三方登錄服務，我們一起來分析一下。
OAuth 機制實現流程
這里以微信開放平臺的接入流程為例：
- 首先，a.com 的運營者需要在微信開放平臺注冊賬號，并向微信申請使用微信登錄功能。
- 申請成功后，得到申請的 appid、appsecret。
- 用戶在 a.com 上選擇使用微信登錄。
- 這時會跳轉微信的 OAuth 授權登錄，并帶上 a.com 的回調地址。
- 用戶輸入微信賬號和密碼，登錄成功后，需要選擇具體的授權范圍，如：授權用戶的頭像、昵稱等。
- 授權之后，微信會根據拉起 a.com?code=123 ，這時帶上了一個臨時票據 code。
- 獲取 code 之后， a.com 會拿著 code 、appid、appsecret，向微信服務器申請 token，驗證成功后，微信會下發一個 token。
- 有了 token 之后， a.com 就可以憑借 token 拿到對應的微信用戶頭像，用戶昵稱等信息了。
- a.com 提示用戶登錄成功，并將登錄狀態寫入 Cooke，以作為后續訪問的憑證。
總結
本文介紹了 4 種常見的登錄方式，原理應該大家都清楚了，總結一下這 4 種方案的使用場景：
- Cookie + Session 歷史悠久，適合于簡單的后端架構，需開發人員自己處理好安全問題。
- Token 方案對后端壓力小，適合大型分布式的后端架構，但已分發出去的 token ，如果想收回權限，就不是很方便了。
- SSO 單點登錄，適用于中大型企業，想要統一內部所有產品的登錄方式。
- OAuth 第三方登錄，簡單易用，對用戶和開發者都友好，但第三方平臺很多，需要選擇合適自己的第三方登錄平臺。
