今天分享的是一位讀者在去年秋招面試抖音被提問的一個問題，剛好刷到一篇不錯的文章解答這個問題，分享一下。
PS：這個問題在面試中還是比較常見的，阿裏、騰訊、用友、京東、小紅書等中大廠的面試都問過這個問題
下面是正文。
前幾天看了極客時間一個二維碼的視訊[1]，寫的不錯，這裏總結下。
在日常生活中，二維碼出現在很多場景，比如超市支付、系統登入、套用下載等等。了解二維碼的原理，可以為技術人員在技術選型時提供新的思路。對於非技術人員呢，除了解惑，還可以引導他更好地辨別生活中遇到的各種二維碼，防止上當受騙。
二維碼，大家再熟悉不過了
購物掃個碼，吃飯掃個碼，坐公交也掃個碼
在掃碼的過程中，大家可能會有疑問：這二維碼安全嗎？會不會泄漏我的個人資訊？更深度的使用者還會考慮：我的系統是不是也可以搞一個二維碼來推廣呢？
這時候就需要了解一下二維碼背後的技術和邏輯了！
二維碼最常用的場景之一就是透過手機端套用掃描 PC 或者 WEB 端的二維碼，來登入同一個系統。比如手機微信掃碼登入 PC 端微信，手機淘寶掃碼登入 PC 端淘寶。那麽就讓我們來看一下，二維碼登入是怎麽操作的！
1
二維碼登入的本質
二維碼登入本質上也是一種登入認證方式。既然是登入認證，要做的也就兩件事情！
告訴系統我是誰
向系統證明我是誰
比如帳號密碼登入，帳號就是告訴系統我是誰， 密碼就是向系統證明我是誰; 比如手機驗證碼登入，手機號就是告訴系統我是誰，驗證碼就是向系統證明我是誰;
那麽掃碼登入是怎麽做到這兩件事情的呢？我們一起來考慮一下。
手機端套用掃 PC 端二維碼，手機端確認後，帳號就在 PC 端登入成功了！這裏，PC 端登入的帳號肯定與手機端是同一個帳號。不可能手機端登入的是帳號 A，而掃碼登入以後，PC 端登入的是帳號 B。
所以，第一件事情，告訴系統我是誰，是比較清楚的！
透過掃描二維碼，把手機端的帳號資訊傳遞到 PC 端，至於是怎麽傳的，我們後面再說
第二件事情，向系統證明我是誰。掃碼登入過程中，使用者並沒有去輸入密碼，也沒有輸入驗證碼，或者其他什麽碼。那是怎麽證明的呢？
有些同學會想到，是不是掃碼過程中，把密碼傳到了 PC 端呢？但這是不可能的。因為那樣太不安全的，客戶端也根本不會去儲存密碼。我們仔細想一下，其實手機端 APP 它是已經登入過的，就是說手機端是已經透過登入認證。 所說只要掃碼確認是這個手機且是這個帳號操作的，其實就能間接證明我誰。
2
認識二維碼
那麽如何做確認呢？我們後面會詳細說明，在這之前我們需要先認識一下二維碼！在認識二維碼之前我們先看一下一維碼！
所謂一維碼，也就是條形碼，超市裏的條形碼--這個相信大家都非常熟悉，條形碼實際上就是一串數位，它上面儲存了商品的序列號。
二維碼其實與條形碼類似，只不過它儲存的不一定是數位，還可以是任何的字串，你可以認為，它就是字串的另外一種表現形式，
在搜尋引擎中搜尋二維碼，你可以找到很多線上生成二維碼的工具網站，這些網站可以提供字串與二維碼之間相互轉換的功能，比如 草料二維碼網站[2]
在左邊的輸入框就可以輸入你的內容，它可以是文本、網址，檔........。然後就可以生成代表它們的二維碼。
你也可以把二維碼上傳，進行」解碼「，然後就可以解析出二維碼代表的含義
3
系統認證機制
認識了二維碼，我們了解一下行動網際網路下的系統認證機制。
前面我們說過，為了安全，手機端它是不會儲存你的登入密碼的。但是在日常使用過程中，我們應該會註意到，只有在你的套用下載下來後，第一次登入的時候，才需要進行一個帳號密碼的登入， 那之後呢 即使這個套用行程被殺掉，或者手機重新開機，都是不需要再次輸入帳號密碼的，它可以自動登入。
其實這背後就是一套基於 token 的認證機制，我們來看一下這套機制是怎麽執行的，
帳號密碼登入時，客戶端會將裝置資訊一起傳遞給伺服端，
如果帳號密碼校驗透過，伺服端會把帳號與裝置進行一個繫結，存在一個數據結構中，這個數據結構中包含了帳號 ID，裝置 ID，裝置型別等等
const token = {
acountid:'帳號ID',
deviceid:'登入的裝置ID',
deviceType:'裝置型別，如 iso,android,pc......',
}
然後伺服端會生成一個 token，用它來對映數據結構，這個 token 其實就是一串有著特殊意義的字串，它的意義就在於，透過它可以找到對應的帳號與裝置資訊。
客戶端得到這個 token 後，需要進行一個本地保存，每次存取系統 API 都攜帶上 token 與裝置資訊。
伺服端就可以透過 token 找到與它繫結的帳號與裝置資訊，然後把繫結的裝置資訊與客戶端每次傳來的裝置資訊進行比較， 如果相同，那麽校驗透過，返回 AP 介面響應數據， 如果不同，那就是校驗不透過拒絕存取。
從前面這個流程，我們可以看到，客戶端不會也沒必要保存你的密碼，相反，它是保存了 token。可能有些同學會想，這個 token 這麽重要，萬一被別人知道了怎麽辦。實際上，知道了也沒有影響， 因為裝置資訊是唯一的，只要你的裝置資訊別人不知道， 別人拿其他裝置來存取，驗證也是不透過的。
可以說，客戶端登入的目的，就是獲得屬於自己的 token。
那麽在掃碼登入過程中，PC 端是怎麽獲得屬於自己的 token 呢？不可能手機端直接把自己的 token 給 PC 端用！token 只能屬於某個客戶端私有，其他人或者是其他客戶端是用不了的。在分析這個問題之前，我們有必要先梳理一下，掃描二維碼登入的一般步驟是什麽樣的。這可以幫助我們梳理清楚整個過程，
4
掃描二維碼登入的一般步驟
大概流程
掃碼前，手機端套用是已登入狀態，PC 端顯示一個二維碼，等待掃描
手機端開啟套用，掃描 PC 端的二維碼，掃描後，會提示"已掃描，請在手機端點選確認"
使用者在手機端點選確認，確認後 PC 端登入就成功了
可以看到，二維碼在中間有三個狀態， 待掃描，已掃描待確認，已確認。那麽可以想象
二維碼的背後它一定存在一個唯一性的 ID，當二維碼生成時，這個 ID 也一起生成，並且繫結了 PC 端的裝置資訊
手機去掃描這個二維碼
二維碼切換為 已掃描待確認狀態， 此時就會將帳號資訊與這個 ID 繫結
當手機端確認登入時，它就會生成 PC 端用於登入的 token，並返回給 PC 端
好了，到這裏，基本思路就已經清晰了，接下來我們把整個過程再具體化一下
二維碼準備
按二維碼不同狀態來看， 首先是等待掃描狀態，使用者開啟 PC 端，切換到二維碼登入界面時。
PC 端向伺服端發起請求，告訴伺服端，我要生成使用者登入的二維碼，並且把 PC 端裝置資訊也傳遞給伺服端
伺服端收到請求後，它生成二維碼 ID，並將二維碼 ID 與 PC 端裝置資訊進行繫結
然後把二維碼 ID 返回給 PC 端
PC 端收到二維碼 ID 後，生成二維碼(二維碼中肯定包含了 ID)
為了及時知道二維碼的狀態，客戶端在展現二維碼後，PC 端不斷的輪詢伺服端，比如每隔一秒就輪詢一次，請求伺服端告訴當前二維碼的狀態及相關資訊
二維碼已經準好了，接下來就是掃描狀態
掃描狀態切換
使用者用手機去掃描 PC 端的二維碼，透過二維碼內容取到其中的二維碼 ID
再呼叫伺服端 API 將移動端的身份資訊與二維碼 ID 一起發送給伺服端
伺服端接收到後，它可以將身份資訊與二維碼 ID 進行繫結，生成臨時 token。然後返回給手機端
因為 PC 端一直在輪詢二維碼狀態，所以這時候二維碼狀態發生了改變，它就可以在界面上把二維碼狀態更新為已掃描
那麽為什麽需要返回給手機端一個臨時 token 呢？臨時 token 與 token 一樣，它也是一種身份憑證，不同的地方在於它只能用一次，用過就失效。
在第三步驟中返回臨時 token，為的就是手機端在下一步操作時，可以用它作為憑證。以此確保掃碼，登入兩步操作是同一部手機端發出的，
狀態確認
最後就是狀態的確認了。
手機端在接收到臨時 token 後會彈出確認登入界面，使用者點選確認時，手機端攜帶臨時 token 用來呼叫伺服端的介面，告訴伺服端，我已經確認
伺服端收到確認後，根據二維碼 ID 繫結的裝置資訊與帳號資訊，生成使用者 PC 端登入的 token
這時候 PC 端的輪詢介面，它就可以得知二維碼的狀態已經變成了"已確認"。並且從伺服端可以獲取到使用者登入的 token
到這裏，登入就成功了，後端 PC 端就可以用 token 去存取伺服端的資源了
掃碼動作的基礎流程都講完了，有些細節還沒有深入介紹，
比如二維碼的內容是什麽？
可以是二維碼 ID
可以是包含二維碼 ID 的一個 url 地址
在掃碼確認這一步，使用者取消了怎麽處理？這些細節都留給大家思考
5
總結
我們從登陸的本質觸發，探索二維碼掃碼登入是如何做到的
告訴系統我是誰
向系統證明我誰
在這個過程中，我們先簡單講了兩個前提知識，
一個是二維碼原理，
一個是基於 token 的認證機制。
然後我們以二維碼狀態為軸，分析了這背後的邏輯: 透過 token 認證機制與二維碼狀態變化來實作掃碼登入.
需要指出的是，前面的講的登入流程，它適用於同一個系統的 PC 端，WEB 端，移動端。
平時我們還有另外一種場景也比較常見，那就是透過第三方套用來掃碼登入，比如極客時間/金塊 都可以選擇微信/QQ 等掃碼登入，那麽這種透過第三方套用掃碼登入又是什麽原理呢？
來源：juejin.cn/post/6940976355097985032
>>
END
精品資料，超贊福利，免費領
微信掃碼/長按辨識 添加【技術交流群】
群內每天分享精品學習資料
最近開發整理了一個用於速刷面試題的小程式；其中收錄了上千道常見面試題及答案(包含基礎、並行、JVM、MySQL、Redis、Spring、SpringMVC、SpringBoot、SpringCloud、訊息佇列等多個型別)，歡迎您的使用。
👇👇
👇點選"閱讀原文"，獲取更多資料（持續更新中）
