1 概述

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

2 登錄原理

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

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

3 實現(xiàn)方案

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

3.1 獲取掃碼狀態(tài)

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

3.1.1 長鏈接

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

方案優(yōu)點：

• 減少不必要的資源訪問浪費；
• 可以準確區(qū)分惡意訪問(掃描漏洞，后面的部分會對這部分進行闡述)并進行限流；
• 當二維碼狀態(tài)變更時，相對于下面的定時輪詢方案有更快的響應速度；

方案缺點：

• 占用服務端大量連接數；
• 由于超時時間通常比較長，需要web端和nginx對這些請求進行特殊的超時配置；

3.1.2 輪詢

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

方案優(yōu)點：

• 符合常規(guī)思維，開發(fā)模式比較簡單易維護；
• 相比阻塞等待方案能夠快速釋放服務端的連接；
• 對于服務端的變更升級也更加友好，因為變更升級會導致服務重啟，采用阻塞方案則可能會造成部分連接斷開；

方案缺點：

• 如果掃碼登錄請求訪問量大，會導致服務端的訪問量一直處于高位；
• 產生了大量的無用訪問，造成資源浪費；
• 無法準確區(qū)分惡意訪問并對其進行合理限流；

3.1.3 長輪詢

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

方案優(yōu)點：

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

方案缺點：

• 讓 Web 端開發(fā)邏輯更加復雜，相當于同時實現(xiàn)了兩種方案；

3.1.4 方案選擇

三種方案各有優(yōu)缺點，應該結合業(yè)務進行選擇。

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

再看看其他廠家選擇：

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

3.2 獲取登錄信息

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

3.2.1 返回 Token

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

方案優(yōu)點：

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

方案缺點：

• 無法支持多站點跨站登錄，即 Web 端服務器只能給一個業(yè)務提供掃碼登錄功能；
• 由于直接返回了 Token，安全風險等級較高；

3.2.2 授權 Ticket

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

方案優(yōu)點：

• 沒有直接傳遞 Token，安全性更好；
• 可以支持多站點跨站登錄身份信息的同步，適用于服務于多站點的掃碼登錄服務；

方案缺點：

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

3.2.3 方案選擇

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

4 安全防護

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

4.1 定時過期

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

4.2 UUID不可遍歷

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

4.3 簽名驗證

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

4.4 合理限流

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

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

5 總結

其實每個方案都有其適用的場景和階段，沒有嚴格意義上的孰優(yōu)孰劣，這個從各互聯(lián)網公司的選擇中也能看出，而要基于自身的需要選擇最合適的方案，切忌盲目選擇最復雜的方案。

到此這篇關于Web端掃碼登錄的原理和實現(xiàn)講解的文章就介紹到這了,更多相關掃碼登錄的原理和實現(xiàn)內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論