登錄認證幾乎是任何一個系統的標配，web 系統、APP、PC 客戶端等，好多都需要註冊、登錄、授權認證。場景說明以一個電商系統，假設淘寶為例，如果我們想要下單，首先需要註冊一個賬號。擁有了賬號之後，我們需要輸入用戶名（比如手機號或郵箱）、密碼完成登錄過程。之後如果你在一段時間內再次進入系統，是不 ...

登錄認證幾乎是任何一個系統的標配，web 系統、APP、PC 客戶端等，好多都需要註冊、登錄、授權認證。

場景說明

以一個電商系統，假設淘寶為例，如果我們想要下單，首先需要註冊一個賬號。擁有了賬號之後，我們需要輸入用戶名（比如手機號或郵箱）、密碼完成登錄過程。之後如果你在一段時間內再次進入系統，是不需要輸入用戶名和密碼的，只有在連續長時間不登錄的情況下（例如一個月沒登錄過）訪問系統，再次需要輸入用戶名和密碼。如果使用頻率很頻繁，通常是一年都不用再輸一次密碼，所以經常在換了一臺電腦或者一部手機之後，一些經常使用的網站或 APP 不記得密碼了。

提煉出來整個過程大概就是如下幾步：

首次使用，需要通過郵箱或手機號註冊；
註冊完成後，需要提供用戶名和密碼完成登錄；
下次再使用，通常不會再次輸入用戶名和密碼即可直接進入系統並使用其功能（除非連續長時間未使用）；

常用的認證方式

OAuth 認證

OAuth 認證比較常見的就是微信登錄、微博登錄、qq登錄等，簡單來說就是利用這些比較權威的網站或應用開放的 API 來實現用戶登錄，用戶可以不用在你的網站或應用上註冊賬號，直接用已有的微信、微博、qq 等賬號登錄。

這一樣一來，即省了用戶註冊的時間，又簡化了你的系統的賬號體系。從而既可以提高用戶註冊率可以節省開發時間，同時，安全性也有了保障。

維基百科對它的解釋摘要如下：

OAuth允許用戶提供一個令牌，而不是用戶名和密碼來訪問他們存放在特定服務提供者的數據。每一個令牌授權一個特定的網站（例如，視頻編輯網站)在特定的時段（例如，接下來的2小時內）內訪問特定的資源（例如僅僅是某一相冊中的視頻）。這樣，OAuth讓用戶可以授權第三方網站訪問他們存儲在另外服務提供者的某些特定信息，而非所有內容。

假設我們開發了一個電商平臺，並集成了微信登錄，以這個場景為例，說一下 OAuth 的工作原理。

講之前需要瞭解其中涉及到的幾個角色：

用戶：即使用我們平臺的用戶
用戶終端：即最終用戶使用的 APP 端或 web 端
應用伺服器端：即我們的伺服器端
授權伺服器端：這裡就是微信處理授權請求的伺服器

好的，接下來開始在我們的電商平臺web端實現微信登錄功能。微信網頁授權是授權碼模式（authorization code）的 OAuth 授權模式。

我們電商平臺的用戶過來登錄，常用場景是點擊“微信登錄”按鈕；
接下來，用戶終端將用戶引導到微信授權頁面；
用戶同意授權，應用伺服器重定向到之前設置好的 redirect_uri （應用伺服器所在的地址），並附帶上授權碼（code）;
應用伺服器用上一步獲取的 code 向微信授權伺服器發送請求，獲取 access_token，也就是上面說的令牌；
之後應用伺服器用上一步獲取的 access_token 去請求微信授權伺服器獲取用戶的基本信息，例如頭像、昵稱等；

早期互聯網以 web 為主，客戶端是瀏覽器，所以 Cookie-Session 方式最那時候最常用的方式，直到現在，一些 web 網站依然用這種方式做認證。

認證過程大致如下：

用戶輸入用戶名、密碼或者用簡訊驗證碼方式登錄系統；
服務端驗證後，創建一個 Session 信息，並且將 SessionID 存到 cookie，發送回瀏覽器；
下次客戶端再發起請求，自動帶上 cookie 信息，服務端通過 cookie 獲取 Session 信息進行校驗；

弊端

只能在 web 場景下使用，如果是 APP 中，不能使用 cookie 的情況下就不能用了；
即使能在 web 場景下使用，也要考慮跨域問題，因為 cookie 不能跨域；
cookie 存在 CSRF（跨站請求偽造）的風險；
如果是分散式服務，需要考慮 Session 同步問題；

由於傳統的 Cookie-Session 認證存在諸多問題，可以把上面的方案改造一下。改動的地方如下：

不用 cookie 做客戶端存儲，改用其他方式，web 下使用 local storage，APP 中使用客戶端資料庫，這樣就實現了跨域，並且避免了 CSRF ;
服務端也不存 Session 了，把 Session 信息拿出來存到 Redis 等記憶體資料庫中，這樣即提高了速度，又避免了 Session 同步問題；

經過改造之後變成瞭如下的認證過程：

用戶輸入用戶名、密碼或者用簡訊驗證碼方式登錄系統；
服務端經過驗證，將認證信息構造好的數據結構存儲到 Redis 中，並將 key 值返回給客戶端；
客戶端拿到返回的 key，存儲到 local storage 或本地資料庫；
下次客戶端再次請求，把 key 值附加到 header 或者請求體中；
服務端根據獲取的 key，到 Redis 中獲取認證信息；

基於JWT的Token認證

上面的方案雖然經過了改版，但還是需要客戶端和伺服器端維持一個狀態信息，比如用 cookie 換 session ,或者用 key 換 Redis 的 value 信息，基於 JWT 的 Token 認證方案可以省去這個過程。

JSON Web Token（JWT）是一個非常輕巧的規範。這個規範允許我們使用JWT在用戶和伺服器之間傳遞安全可靠的信息。

認證過程

依然是用戶登錄系統；
服務端驗證，將認證信息通過指定的演算法（例如HS256）進行加密，例如對用戶名和用戶所屬角色進行加密，加密私鑰是保存在伺服器端的，將加密後的結果發送給客戶端，加密的字元串格式為三個"." 分隔的字元串 Token，分別對應頭部、載荷與簽名，頭部和載荷都可以通過 base64 解碼出來，簽名部分不可以；
客戶端拿到返回的 Token，存儲到 local storage 或本地資料庫；
下次客戶端再次發起請求，將 Token 附加到 header 中；
服務端獲取 header 中的 Token ，通過相同的演算法對 Token 中的用戶名和所屬角色進行相同的加密驗證，如果驗證結果相同，則說明這個請求是正常的，沒有被篡改。這個過程可以完全不涉及到查詢 Redis 或其他存儲；

優點