今天分享的是一位讀者在去年秋招面試抖音被提問的一個問題，剛好刷到一篇不錯的文章解答這個問題，分享一下。PS：這個問題在面試中還是比較常見的，阿里、騰訊、用友、京東、小紅書等中大廠的面試都問過這個問題
前幾天看了極客時間一個二維碼的視頻[1]，寫的不錯，這里總結(jié)下。
?在日常生活中，二維碼出現(xiàn)在很多場景，比如超市支付、系統(tǒng)登錄、應用下載等等。了解二維碼的原理，可以為技術(shù)人員在技術(shù)選型時提供新的思路。對于非技術(shù)人員呢，除了解惑，還可以引導他更好地辨別生活中遇到的各種二維碼，防止上當受騙。在掃碼的過程中，大家可能會有疑問：這二維碼安全嗎？會不會泄漏我的個人信息？更深度的用戶還會考慮：我的系統(tǒng)是不是也可以搞一個二維碼來推廣呢？這時候就需要了解一下二維碼背后的技術(shù)和邏輯了！二維碼最常用的場景之一就是通過手機端應用掃描 PC 或者 WEB 端的二維碼，來登錄同一個系統(tǒng)。比如手機微信掃碼登錄 PC 端微信，手機淘寶掃碼登錄 PC 端淘寶。那么就讓我們來看一下，二維碼登錄是怎么操作的！
二維碼登錄本質(zhì)上也是一種登錄認證方式。既然是登錄認證，要做的也就兩件事情！
比如賬號密碼登錄，賬號就是告訴系統(tǒng)我是誰， 密碼就是向系統(tǒng)證明我是誰; 比如手機驗證碼登錄，手機號就是告訴系統(tǒng)我是誰，驗證碼就是向系統(tǒng)證明我是誰;那么掃碼登錄是怎么做到這兩件事情的呢？我們一起來考慮一下。手機端應用掃 PC 端二維碼，手機端確認后，賬號就在 PC 端登錄成功了！這里，PC 端登錄的賬號肯定與手機端是同一個賬號。不可能手機端登錄的是賬號 A，而掃碼登錄以后，PC 端登錄的是賬號 B。所以，第一件事情，告訴系統(tǒng)我是誰，是比較清楚的！通過掃描二維碼，把手機端的賬號信息傳遞到 PC 端，至于是怎么傳的，我們后面再說第二件事情，向系統(tǒng)證明我是誰。掃碼登錄過程中，用戶并沒有去輸入密碼，也沒有輸入驗證碼，或者其他什么碼。那是怎么證明的呢？有些同學會想到，是不是掃碼過程中，把密碼傳到了 PC 端呢？但這是不可能的。因為那樣太不安全的，客戶端也根本不會去存儲密碼。我們仔細想一下，其實手機端 APP 它是已經(jīng)登錄過的，就是說手機端是已經(jīng)通過登錄認證。所說只要掃碼確認是這個手機且是這個賬號操作的，其實就能間接證明我誰。
那么如何做確認呢？我們后面會詳細說明，在這之前我們需要先認識一下二維碼！在認識二維碼之前我們先看一下一維碼！所謂一維碼，也就是條形碼，超市里的條形碼--這個相信大家都非常熟悉，條形碼實際上就是一串數(shù)字，它上面存儲了商品的序列號。二維碼其實與條形碼類似，只不過它存儲的不一定是數(shù)字，還可以是任何的字符串，你可以認為，它就是字符串的另外一種表現(xiàn)形式，在搜索引擎中搜索二維碼，你可以找到很多在線生成二維碼的工具網(wǎng)站，這些網(wǎng)站可以提供字符串與二維碼之間相互轉(zhuǎn)換的功能，比如 草料二維碼網(wǎng)站[2]在左邊的輸入框就可以輸入你的內(nèi)容，它可以是文本、網(wǎng)址，文件........。然后就可以生成代表它們的二維碼。你也可以把二維碼上傳，進行”解碼“，然后就可以解析出二維碼代表的含義
認識了二維碼，我們了解一下移動互聯(lián)網(wǎng)下的系統(tǒng)認證機制。前面我們說過，為了安全，手機端它是不會存儲你的登錄密碼的。但是在日常使用過程中，我們應該會注意到，只有在你的應用下載下來后，第一次登錄的時候，才需要進行一個賬號密碼的登錄， 那之后呢 即使這個應用進程被殺掉，或者手機重啟，都是不需要再次輸入賬號密碼的，它可以自動登錄。其實這背后就是一套基于 token 的認證機制，我們來看一下這套機制是怎么運行的，
- 賬號密碼登錄時，客戶端會將設備信息一起傳遞給服務端，
- 如果賬號密碼校驗通過，服務端會把賬號與設備進行一個綁定，存在一個數(shù)據(jù)結(jié)構(gòu)中，這個數(shù)據(jù)結(jié)構(gòu)中包含了賬號 ID，設備 ID，設備類型等等
const token = {
acountid:'賬號ID',
deviceid:'登錄的設備ID',
deviceType:'設備類型，如 iso,android,pc......',
}
然后服務端會生成一個 token，用它來映射數(shù)據(jù)結(jié)構(gòu)，這個 token 其實就是一串有著特殊意義的字符串，它的意義就在于，通過它可以找到對應的賬號與設備信息。
- 客戶端得到這個 token 后，需要進行一個本地保存，每次訪問系統(tǒng) API 都攜帶上 token 與設備信息。
- 服務端就可以通過 token 找到與它綁定的賬號與設備信息，然后把綁定的設備信息與客戶端每次傳來的設備信息進行比較， 如果相同，那么校驗通過，返回 AP 接口響應數(shù)據(jù)， 如果不同，那就是校驗不通過拒絕訪問。
從前面這個流程，我們可以看到，客戶端不會也沒必要保存你的密碼，相反，它是保存了 token。可能有些同學會想，這個 token 這么重要，萬一被別人知道了怎么辦。實際上，知道了也沒有影響， 因為設備信息是唯一的，只要你的設備信息別人不知道， 別人拿其他設備來訪問，驗證也是不通過的。可以說，客戶端登錄的目的，就是獲得屬于自己的 token。那么在掃碼登錄過程中，PC 端是怎么獲得屬于自己的 token 呢？不可能手機端直接把自己的 token 給 PC 端用！token 只能屬于某個客戶端私有，其他人或者是其他客戶端是用不了的。在分析這個問題之前，我們有必要先梳理一下，掃描二維碼登錄的一般步驟是什么樣的。這可以幫助我們梳理清楚整個過程，
- 掃碼前，手機端應用是已登錄狀態(tài)，PC 端顯示一個二維碼，等待掃描
- 手機端打開應用，掃描 PC 端的二維碼，掃描后，會提示"已掃描，請在手機端點擊確認"
- 用戶在手機端點擊確認，確認后 PC 端登錄就成功了
可以看到，二維碼在中間有三個狀態(tài)， 待掃描，已掃描待確認，已確認。那么可以想象
- 二維碼的背后它一定存在一個唯一性的 ID，當二維碼生成時，這個 ID 也一起生成，并且綁定了 PC 端的設備信息
- 二維碼切換為 已掃描待確認狀態(tài)， 此時就會將賬號信息與這個 ID 綁定
- 當手機端確認登錄時，它就會生成 PC 端用于登錄的 token，并返回給 PC 端
好了，到這里，基本思路就已經(jīng)清晰了，接下來我們把整個過程再具體化一下按二維碼不同狀態(tài)來看， 首先是等待掃描狀態(tài)，用戶打開 PC 端，切換到二維碼登錄界面時。
- PC 端向服務端發(fā)起請求，告訴服務端，我要生成用戶登錄的二維碼，并且把 PC 端設備信息也傳遞給服務端
- 服務端收到請求后，它生成二維碼 ID，并將二維碼 ID 與 PC 端設備信息進行綁定
- PC 端收到二維碼 ID 后，生成二維碼(二維碼中肯定包含了 ID)
- 為了及時知道二維碼的狀態(tài)，客戶端在展現(xiàn)二維碼后，PC 端不斷的輪詢服務端，比如每隔一秒就輪詢一次，請求服務端告訴當前二維碼的狀態(tài)及相關(guān)信息
二維碼已經(jīng)準好了，接下來就是掃描狀態(tài)
- 用戶用手機去掃描 PC 端的二維碼，通過二維碼內(nèi)容取到其中的二維碼 ID
- 再調(diào)用服務端 API 將移動端的身份信息與二維碼 ID 一起發(fā)送給服務端
- 服務端接收到后，它可以將身份信息與二維碼 ID 進行綁定，生成臨時 token。然后返回給手機端
- 因為 PC 端一直在輪詢二維碼狀態(tài)，所以這時候二維碼狀態(tài)發(fā)生了改變，它就可以在界面上把二維碼狀態(tài)更新為已掃描
那么為什么需要返回給手機端一個臨時 token 呢？臨時 token 與 token 一樣，它也是一種身份憑證，不同的地方在于它只能用一次，用過就失效。在第三步驟中返回臨時 token，為的就是手機端在下一步操作時，可以用它作為憑證。以此確保掃碼，登錄兩步操作是同一部手機端發(fā)出的，
- 手機端在接收到臨時 token 后會彈出確認登錄界面，用戶點擊確認時，手機端攜帶臨時 token 用來調(diào)用服務端的接口，告訴服務端，我已經(jīng)確認
- 服務端收到確認后，根據(jù)二維碼 ID 綁定的設備信息與賬號信息，生成用戶 PC 端登錄的 token
- 這時候 PC 端的輪詢接口，它就可以得知二維碼的狀態(tài)已經(jīng)變成了"已確認"。并且從服務端可以獲取到用戶登錄的 token
- 到這里，登錄就成功了，后端 PC 端就可以用 token 去訪問服務端的資源了
掃碼動作的基礎(chǔ)流程都講完了，有些細節(jié)還沒有深入介紹，
在掃碼確認這一步，用戶取消了怎么處理？這些細節(jié)都留給大家思考
我們從登陸的本質(zhì)觸發(fā)，探索二維碼掃碼登錄是如何做到的
然后我們以二維碼狀態(tài)為軸，分析了這背后的邏輯: 通過 token 認證機制與二維碼狀態(tài)變化來實現(xiàn)掃碼登錄.需要指出的是，前面的講的登錄流程，它適用于同一個系統(tǒng)的 PC 端，WEB 端，移動端。平時我們還有另外一種場景也比較常見，那就是通過第三方應用來掃碼登錄，比如極客時間/掘金 都可以選擇微信/QQ 等掃碼登錄，那么這種通過第三方應用掃碼登錄又是什么原理呢？來源：juejin.cn/post/6940976355097985032
閱讀原文：原文鏈接
該文章在 2025/3/24 17:19:22 編輯過
400 186 1886
