說一說常用的登錄認證方式

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

場景說明

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

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

弊端

• 只能在 web 場景下使用，如果是 APP 中，不能使用 cookie 的情況下就不能用了；

• 即使能在 web 場景下使用，也要考慮跨域問題，因為 cookie 不能跨域；

• cookie 存在 CSRF（跨站請求偽造）的風險；

• 如果是分散式服務，需要考慮 Session 同步問題；

  Cookie-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 或其他存儲；

優點

• 使用 json 作為數據傳輸，有廣泛的通用型，並且體積小，便於傳輸；

• 不需要在伺服器端保存相關信息；

• jwt 載荷部分可以存儲業務相關的信息（非敏感的），例如用戶信息、角色等；

  總結

  綜上所述，JWT 可以作為首選的認證方案。當然，具體的情況具體分析，還要看是不是適合真實的應用場景。除了上述的這些，涉及到信息安全的，建議全部採用 https 方式部署，採用 https 方式，信息很難被嗅探破解，對應用的安全性很重要。

  參考信息：

  OAuth:http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

  JWT：https://jwt.io/introduction/

  http://blog.leapoahead.com/2015/09/06/understanding-jwt/

  JWT Java 庫:https://github.com/jwtk/jjwt

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！