掃碼登錄，其實相當於一種授權機制。
一、交互
二維碼登錄是一個涉及三方的交互過程：web 瀏覽器、移動端，服務后台。
基本交互流程如下：
a）web 瀏覽器：負責二維碼的展示及移動端授權后的登錄態展示。
b）移動端：負責掃碼及授權。
c）服務后台：貫穿整個交互過程。
二、登錄二位碼
想要掃碼登錄，首先必須得有碼。
二維碼是一種特殊的數據載體，作為登錄二維碼，他首先必須具備一定的特性：
1、唯一性
首先有一個前提需要明確的是：每一個二維碼都必須是惟一的。或者嚴格一點說，當前存續期間的每一個二維碼都必須是惟一的。
唯一，就要求二維碼承載的數據必須有一部分能給它提供區分標識。
那怎么生成這樣一個唯一標識呢？
方法，機制可能會很多，在這里我們只就其中一種做簡要介紹：基於分布式緩存+隨機數的生成機制
a）隨機
隨機數可以提供一定程度上的區分度，這依賴於隨機數的生成原理，不同生成算法所生成的隨機數區分度差別會很大。
b）分布式緩存
隨機數可能重復，這可能是個必然的問題，所以我們進一步使用分布式緩存來保障標識的唯一性。
分布式緩存我們選取 redis 作為載體。基於鍵的的唯一性，我們通過將上一步驟生成的隨機數寫入分布式緩存，並添加特定次數重試機制來維護唯一標識數據。
2、時效性
登錄二維碼需要有限制的存續周期，這是提供安全性的基本保障。
登錄鑒權是一個及其敏感的過程，數據的持續暴露通常會導致不可預知的安全性問題。存續周期通常選取在秒級別，不同的業務生態可以基於自身需求靈活調整。
3、二維碼數據
我們可以把一個完整的訪問鏈接（附帶唯一標識及特定的參數）放入二維碼，提供給移動端掃描。
這里需要注意的一點是，放入的數據量會直接影響生成的二維碼圖形的密集程度，過密的圖形可能會帶來不好的掃碼體驗。
二維碼圖形的生成有兩種形式可以選擇：服務端生成，web瀏覽器生成。
a）服務端生成：服務端直接生成二維碼圖形數據，web 瀏覽器只負責圖形的展示，減少端上的業務復雜度。
b）web 瀏覽器生成：后台服務只負責提供二維碼內部數據，圖形的生成放到 web 瀏覽器方。這樣做的好處是減少了數據傳輸的量，同時，考慮到服務端變更的成本問題，web 瀏覽器處理圖形生成可以更靈活的定制不同樣式的展示。
三、登錄二維碼狀態
登錄二維碼是整個交互流程的核心，我們這里通過登錄二維碼的狀態來標識不同的操作步驟。
1、狀態定義
a）待掃碼
二維碼生成完成后的狀態。此時二維碼處於待掃碼狀態。
b）已掃碼
移動端掃碼完成后，二維碼需要更新為已掃碼狀態，web 瀏覽器獲取到此狀態，需要作相應的狀態展示“已掃待確認”。
c）已確認
移動端掃碼完成后，會有相應的提示“確認登錄”操作，用戶執行完“確認登錄”后，二維碼更新為已確認狀態。
d）已登錄
用戶確認登錄后，web 瀏覽器獲取到“已確認”狀態，可以進一步執行相應的登錄態展示操作。同時將二維碼狀態更新為已登錄，保證登錄態的處理只執行一次。
e）已失效
失效產生的場景包括：移動端掃碼完成后，如果用戶執行取消操作（如果有），則可以執行相應的二維碼數據刪除操作（非必須），或者待登錄二維碼存續時間到期，二維碼數據消失。
此時 web 瀏覽器查詢到此狀態則需要處理重新生成二維碼的操作。二維碼生成的觸發，可以是引導用戶主動操作刷新，或者 web 瀏覽器自動機制維持保持有效二維碼展示。業務方可以基於用戶體驗和服務壓力兩方面權衡去抉擇。
2、狀態查詢
基於上述登錄二維狀態流轉，web 瀏覽器需要在每一步都確保實時獲悉登錄二維碼的狀態。
可選的做法通常有輪訓，websocket長鏈接等。
a）輪訓
web 瀏覽器間斷的向服務后台發送請求查詢狀態。每次查詢，服務端可以快速返回（減少連接長時間占用），亦可以等待一段時間再返回（減少請求次數）。
b）websocket長鏈接
基於 websocket 長鏈接，后台服務可以實時推送登錄二維碼狀態到前台。當然，這需要相應 web 技術支持。