Web端掃碼登錄的原理和實現方法是什么

這篇文章主要介紹了Web端掃碼登錄的原理和實現方法是什么的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇Web端掃碼登錄的原理和實現方法是什么文章都會有所收獲，下面我們一起來看看吧。

1 概述

在日常 Web 端產品的使用中，一般都會支持掃碼登錄，這種方式操作簡單，相對傳統的手機號登錄等方式速度更快、安全性更高，還可以增加自家產品的粘合度。

2 登錄原理

掃碼登錄本質是解決將 APP 端的用戶登錄信息（通常是 Token）通過掃碼的形式安全穩定地同步給 Web 端。

1）用戶打開 Web 端網頁，進入掃碼登錄的界面；
2）從 Web 端服務器獲取二維碼的圖并獲取其狀態；
3）Web 端服務器在生成二維碼時，會生成一個 uuid 和二維碼進行關聯，并將 uuid 存入 db 記錄中；
4）用戶打開 APP 端，對著二維碼進行掃碼授權操作；
5）APP 客戶端從二維碼中讀取到 uuid，帶著 APP 內的身份信息訪問 APP 端服務器；
6）APP 端服務器獲取到用戶的身份信息后，將用戶 id 更新到 db 中對應 uuid 的記錄中，此時 Web 服務器就能拿到對應的用戶 id，之后生成登錄身份信息返回給瀏覽器，即用戶在 Web 端完成了登錄；

3 實現方案

基于以上分析，我們可以將掃碼登錄分為兩個步驟：獲取掃碼狀態和獲取用戶登錄信息。

3.1 獲取掃碼狀態

用戶在 Web 端頁面看到二維碼信息后，會使用客戶端進行掃碼授權，而 Web 端需要盡快獲取到二維碼的狀態(已掃碼、已過期、已取消、已授權)并同步到網頁中展示給用戶, 現在有3種方案：

3.1.1 長鏈接

Web 端訪問服務器獲取二維碼狀態時，服務器是阻塞了請求，等到二維碼的狀態變更后才會返回結果，這種請求都會有超時配置(通常是幾分鐘)，但又不能無限等待。

方案優點：

• 減少不必要的資源訪問浪費；

• 可以準確區分惡意訪問(掃描漏洞，后面的部分會對這部分進行闡述)并進行限流；

• 當二維碼狀態變更時，相對于下面的定時輪詢方案有更快的響應速度；

方案缺點：

• 占用服務端大量連接數；

• 由于超時時間通常比較長，需要web端和nginx對這些請求進行特殊的超時配置；

3.1.2 輪詢

Web 端每隔一個固定時間(為了更好的用戶體驗通常選擇為 1 秒)訪問服務器獲取二維碼的狀態并進行展示。

方案優點：

• 符合常規思維，開發模式比較簡單易維護；

• 相比阻塞等待方案能夠快速釋放服務端的連接；

• 對于服務端的變更升級也更加友好，因為變更升級會導致服務重啟，采用阻塞方案則可能會造成部分連接斷開；

方案缺點：

• 如果掃碼登錄請求訪問量大，會導致服務端的訪問量一直處于高位；

• 產生了大量的無用訪問，造成資源浪費；

• 無法準確區分惡意訪問并對其進行合理限流；

3.1.3 長輪詢

長輪詢即結合了長鏈接和定時輪詢的優點，Web 端訪問服務器獲取二維碼狀態時，服務器依然會阻塞了請求，但是超時時間會相對比較短(比如15秒)，超時后 Web 端會繼續發起請求，如此往復。

方案優點：

• 結合了阻塞等待和定時輪詢的優點，削弱了兩個方案的的缺點；

方案缺點：

• 讓 Web 端開發邏輯更加復雜，相當于同時實現了兩種方案；

3.1.4 方案選擇

三種方案各有優缺點，應該結合業務進行選擇。

先以微信公眾平臺為例，進入其掃碼登錄頁，就會發現密密麻麻的調用獲取掃碼狀態請求過程，很明顯是采用了輪詢方案。

再看看其他廠家選擇：

平臺方案微信開放平臺長輪詢微信公眾平臺輪詢京東輪詢淘寶&&天貓輪詢百度長輪詢B 站輪詢快手長鏈接

從上面可以看出目前主流方案是定時輪詢，這是由于掃碼登錄本身也是低頻操作，并不會造成很大量的請求，但優點又比較突出。

3.2 獲取登錄信息

當用戶掃碼登錄后，Web 服務器如何將用戶信息（如 Token）同步給 Web 端。

3.2.1 返回 Token

指直接返回用戶登錄信息 Token。

方案優點：

• 流程簡單，完成掃描授權后流程后直接結束；

方案缺點：

• 無法支持多站點跨站登錄，即 Web 端服務器只能給一個業務提供掃碼登錄功能；

• 由于直接返回了 Token，安全風險等級較高；

3.2.2 授權 Ticket

Web 端服務器在掃碼完成后，返回的是一個授權 Ticket（也可以直接返回帶 Ticket 的授權 url, 便于 Web 端直接跳轉），之后需要 Web 端帶著這個 Ticket 調用目標服務器的接口進行身份的驗證同步，如圖所示：

方案優點：

• 沒有直接傳遞 Token，安全性更好；

• 可以支持多站點跨站登錄身份信息的同步，適用于服務于多站點的掃碼登錄服務；

方案缺點：

• 實現邏輯較為復雜，需要維護完整的授權 Ticket 生成、校驗以及失效邏輯；

3.2.3 方案選擇

平臺方案微信開放平臺授權Ticket微信公眾平臺Token京東授權Ticket淘寶&&天貓授權Ticket百度授權TicketB 站授權Ticket快手授權Ticket

經過調研發現，在國內互聯網各大廠商中返回授權 Ticket 的方案被較多采用，這也由于各家旗下擁有眾多 PC Web 站，直接返回 Token 的方案無法多站點的登錄信息同步，而上面表格中亦有一個另類——微信公眾平臺，大概與其產品獨立性有關。

4 安全防護

前面提到，掃碼登錄的本質是通過掃碼手段安全穩定地同步用戶信息。那么我們可以通過哪些手段提高同步過程中的安全性？

4.1 定時過期

每個二維碼都有一個唯一的 uuid 與之對應，為了防止惡意人員通過接口遍歷查詢以獲取之前已經被掃的二維碼信息，數據不能永久存儲于db中，需要完成掃碼后從 db 刪除或者定期過期清除。

4.2 UUID不可遍歷

簡單的方案是將自增 ID 和一個固定 salt 進行 md5 之后生成一個字符串作為uuid；也可以通過 UUID.randomUUID() 生成一個隨機字符串。當然，還可以采用對稱加密的方式存儲一些加密信息。

4.3 簽名驗證

這個方式關鍵點在于將 uuid 和請求中的 Cookie 或參數信息經過哈希算法得到一個 signature 值，此時即使有人破解了 uuid 的生成規則，只能生成uuid，但是無法獲知對應 uuid 生成時對應的 Web 端狀態(Cookie)，因此破解了 uuid 后也無法獲取對應 signature 值，也就無法獲取二維碼狀態。

4.4 合理限流

一般是在獲取二維碼階段對來源 IP 進行訪問的限制。

當然掃描二維碼階段也可以做限流，但是如果采用是定時輪詢方案，由于訪問次數太多，無法做到精確識別和控制，可操作性不強；而如果采用的是阻塞等待方案，也能進行限流，但是如果已經采用了上面參數簽名驗證，則可以把惡意用戶都收口在獲取二維碼階段，在這個階段限流的意義不大。

關于“Web端掃碼登錄的原理和實現方法是什么”這篇文章的內容就介紹到這里，感謝各位的閱讀！相信大家對“Web端掃碼登錄的原理和實現方法是什么”知識都有一定的了解，大家如果還想學習更多知識，歡迎關注億速云行業資訊頻道。