Web端掃碼登入的原理和實現講解

2023-03-23 22:02:23

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 值，也就無法獲取二維條碼狀態。