掃碼登入，其實相當於一種授權機制。
一、互動
二維碼登入是一個涉及三方的互動過程：web 瀏覽器、移動端，服務後臺。
基本互動流程如下：
a）web 瀏覽器：負責二維碼的展示及移動端授權後的登入態展示。
b）移動端：負責掃碼及授權。
c）服務後臺：貫穿整個互動過程。
二、登入二位碼
想要掃碼登入，首先必須得有碼。
二維碼是一種特殊的資料載體，作為登入二維碼，他首先必須具備一定的特性：
1、唯一性
首先有一個前提需要明確的是：每一個二維碼都必須是惟一的。或者嚴格一點說，當前存續期間的每一個二維碼都必須是惟一的。
唯一，就要求二維碼承載的資料必須有一部分能給它提供區分標識。
那怎麼生成這樣一個唯一標識呢？
方法，機制可能會很多，在這裡我們只就其中一種做簡要介紹：基於分散式快取+隨機數的生成機制
a）隨機
隨機數可以提供一定程度上的區分度，這依賴於隨機數的生成原理，不同生成演算法所生成的隨機數區分度差別會很大。
這裡我們選取 UUID 方式來提供基礎的隨機數生成。鑑於 UUID 的長度問題，我們可以去掉其中的連線符號。
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 技術支援。