1 概述

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

2 登錄原理

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

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

3 實(shí)現(xiàn)方案

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

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

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

3.1.1 長(zhǎng)鏈接

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

方案優(yōu)點(diǎn)：

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

方案缺點(diǎn)：

• 占用服務(wù)端大量連接數(shù)；
• 由于超時(shí)時(shí)間通常比較長(zhǎng)，需要web端和nginx對(duì)這些請(qǐng)求進(jìn)行特殊的超時(shí)配置；

3.1.2 輪詢

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

方案優(yōu)點(diǎn)：

• 符合常規(guī)思維，開(kāi)發(fā)模式比較簡(jiǎn)單易維護(hù)；
• 相比阻塞等待方案能夠快速釋放服務(wù)端的連接；
• 對(duì)于服務(wù)端的變更升級(jí)也更加友好，因?yàn)樽兏?jí)會(huì)導(dǎo)致服務(wù)重啟，采用阻塞方案則可能會(huì)造成部分連接斷開(kāi)；

方案缺點(diǎn)：

• 如果掃碼登錄請(qǐng)求訪問(wèn)量大，會(huì)導(dǎo)致服務(wù)端的訪問(wèn)量一直處于高位；
• 產(chǎn)生了大量的無(wú)用訪問(wèn)，造成資源浪費(fèi)；
• 無(wú)法準(zhǔn)確區(qū)分惡意訪問(wèn)并對(duì)其進(jìn)行合理限流；

3.1.3 長(zhǎng)輪詢

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

方案優(yōu)點(diǎn)：

• 結(jié)合了阻塞等待和定時(shí)輪詢的優(yōu)點(diǎn)，削弱了兩個(gè)方案的的缺點(diǎn)；

方案缺點(diǎn)：

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

3.1.4 方案選擇

三種方案各有優(yōu)缺點(diǎn)，應(yīng)該結(jié)合業(yè)務(wù)進(jìn)行選擇。

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

再看看其他廠家選擇：

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

3.2 獲取登錄信息

當(dāng)用戶掃碼登錄后，Web 服務(wù)器如何將用戶信息（如 Token）同步給 Web 端。

3.2.1 返回 Token

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

方案優(yōu)點(diǎn)：

• 流程簡(jiǎn)單，完成掃描授權(quán)后流程后直接結(jié)束；

方案缺點(diǎn)：

• 無(wú)法支持多站點(diǎn)跨站登錄，即 Web 端服務(wù)器只能給一個(gè)業(yè)務(wù)提供掃碼登錄功能；
• 由于直接返回了 Token，安全風(fēng)險(xiǎn)等級(jí)較高；

3.2.2 授權(quán) Ticket

Web 端服務(wù)器在掃碼完成后，返回的是一個(gè)授權(quán) Ticket（也可以直接返回帶 Ticket 的授權(quán) url, 便于 Web 端直接跳轉(zhuǎn)），之后需要 Web 端帶著這個(gè) Ticket 調(diào)用目標(biāo)服務(wù)器的接口進(jìn)行身份的驗(yàn)證同步，如圖所示：

方案優(yōu)點(diǎn)：

• 沒(méi)有直接傳遞 Token，安全性更好；
• 可以支持多站點(diǎn)跨站登錄身份信息的同步，適用于服務(wù)于多站點(diǎn)的掃碼登錄服務(wù)；

方案缺點(diǎn)：

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

3.2.3 方案選擇

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

4 安全防護(hù)

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

4.1 定時(shí)過(guò)期

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

4.2 UUID不可遍歷

簡(jiǎn)單的方案是將自增 ID 和一個(gè)固定 salt 進(jìn)行 md5 之后生成一個(gè)字符串作為uuid；也可以通過(guò) UUID.randomUUID() 生成一個(gè)隨機(jī)字符串。當(dāng)然，還可以采用對(duì)稱加密的方式存儲(chǔ)一些加密信息。

4.3 簽名驗(yàn)證

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

4.4 合理限流

一般是在獲取二維碼階段對(duì)來(lái)源 IP 進(jìn)行訪問(wèn)的限制。

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

5 總結(jié)

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

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

最新評(píng)論