二維碼掃碼登錄是什麼原理

在日常生活中，二維碼出現在很多場景，比如超市支付、系統登錄、應用下載等等。瞭解二維碼的原理，可以爲技術人員在技術選型時提供新的思路。對於非技術人員呢，除了解惑，還可以引導他更好地辨別生活中遇到的各種二維碼，防止上當受騙。

二維碼，大家再熟悉不過了

購物掃個碼，喫飯掃個碼，坐公交也掃個碼

在掃碼的過程中，大家可能會有疑問：這二維碼安全嗎？會不會泄漏我的個人信息？更深度的用戶還會考慮：我的系統是不是也可以搞一個二維碼來推廣呢？

這時候就需要了解一下二維碼背後的技術和邏輯了！

二維碼最常用的場景之一就是通過手機端應用掃描 PC 或者 WEB 端的二維碼，來登錄同一個系統。比如手機微信掃碼登錄 PC 端微信，手機淘寶掃碼登錄 PC 端淘寶。那麼就讓我們來看一下，二維碼登錄是怎麼操作的！

二維碼登錄的本質

二維碼登錄本質上也是一種登錄認證方式。既然是登錄認證，要做的也就兩件事情！

  1. 告訴系統我是誰

  2. 向系統證明我是誰

比如賬號密碼登錄，賬號就是告訴系統我是誰， 密碼就是向系統證明我是誰; 比如手機驗證碼登錄，手機號就是告訴系統我是誰，驗證碼就是向系統證明我是誰;

那麼掃碼登錄是怎麼做到這兩件事情的呢？我們一起來考慮一下

手機端應用掃 PC 端二維碼，手機端確認後，賬號就在 PC 端登錄成功了！這裏，PC 端登錄的賬號肯定與手機端是同一個賬號。不可能手機端登錄的是賬號 A，而掃碼登錄以後，PC 端登錄的是賬號 B。

所以，第一件事情，告訴系統我是誰，是比較清楚的！

通過掃描二維碼，把手機端的賬號信息傳遞到 PC 端，至於是怎麼傳的，我們後面再說

第二件事情，向系統證明我是誰。掃碼登錄過程中，用戶並沒有去輸入密碼，也沒有輸入驗證碼，或者其他什麼碼。那是怎麼證明的呢？

有些同學會想到，是不是掃碼過程中，把密碼傳到了 PC 端呢？但這是不可能的。因爲那樣太不安全的，客戶端也根本不會去存儲密碼。我們仔細想一下，其實手機端 APP 它是已經登錄過的，就是說手機端是已經通過登錄認證。所說只要掃碼確認是這個手機且是這個賬號操作的，其實就能間接證明我誰。

認識二維碼

那麼如何做確認呢？我們後面會詳細說明，在這之前我們需要先認識一下二維碼！在認識二維碼之前我們先看一下一維碼！

所謂一維碼，也就是條形碼，超市裏的條形碼 -- 這個相信大家都非常熟悉，條形碼實際上就是一串數字，它上面存儲了商品的序列號。

二維碼其實與條形碼類似，只不過它存儲的不一定是數字，還可以是任何的字符串，你可以認爲，它就是字符串的另外一種表現形式，

在搜索引擎中搜索二維碼，你可以找到很多在線生成二維碼的工具網站，這些網站可以提供字符串與二維碼之間相互轉換的功能.

在左邊的輸入框就可以輸入你的內容，它可以是文本、網址，文件........。然後就可以生成代表它們的二維碼

你也可以把二維碼上傳，進行” 解碼 “，然後就可以解析出二維碼代表的含義

系統認證機制

認識了二維碼，我們瞭解一下移動互聯網下的系統認證機制。

前面我們說過，爲了安全，手機端它是不會存儲你的登錄密碼的。但是在日常使用過程中，我們應該會注意到，只有在你的應用下載下來後，第一次登錄的時候，才需要進行一個賬號密碼的登錄， 那之後呢 即使這個應用進程被殺掉，或者手機重啓，都是不需要再次輸入賬號密碼的，它可以自動登錄。

其實這背後就是一套基於 token 的認證機制，我們來看一下這套機制是怎麼運行的，

  1. 賬號密碼登錄時，客戶端會將設備信息一起傳遞給服務端，
  2. 如果賬號密碼校驗通過，服務端會把賬號與設備進行一個綁定，存在一個數據結構中，這個數據結構中包含了賬號ID，設備ID，設備類型等等
const token = {
  acountid:'賬號ID',
  deviceid:'登錄的設備ID',
  deviceType:'設備類型，如 iso,android,pc......',
}

然後服務端會生成一個 token，用它來映射數據結構，這個 token 其實就是一串有着特殊意義的字符串，它的意義就在於，通過它可以找到對應的賬號與設備信息，

  1. 客戶端得到這個 token 後，需要進行一個本地保存，每次訪問系統 API 都攜帶上 token 與設備信息。

  2. 服務端就可以通過 token 找到與它綁定的賬號與設備信息，然後把綁定的設備信息與客戶端每次傳來的設備信息進行比較， 如果相同，那麼校驗通過，返回 AP 接口響應數據， 如果不同，那就是校驗不通過拒絕訪問

從前面這個流程，我們可以看到，客戶端不會也沒必要保存你的密碼，相反，它是保存了 token。可能有些同學會想，這個 token 這麼重要，萬一被別人知道了怎麼辦。實際上，知道了也沒有影響， 因爲設備信息是唯一的，只要你的設備信息別人不知道， 別人拿其他設備來訪問，驗證也是不通過的。

可以說，客戶端登錄的目的，就是獲得屬於自己的 token。

那麼在掃碼登錄過程中，PC 端是怎麼獲得屬於自己的 token 呢？不可能手機端直接把自己的 token 給 PC 端用！token 只能屬於某個客戶端私有，其他人或者是其他客戶端是用不了的。在分析這個問題之前，我們有必要先梳理一下，掃描二維碼登錄的一般步驟是什麼樣的。這可以幫助我們梳理清楚整個過程，

掃描二維碼登錄的一般步驟

大概流程

  1. 掃碼前，手機端應用是已登錄狀態，PC 端顯示一個二維碼，等待掃描

  2. 手機端打開應用，掃描 PC 端的二維碼，掃描後，會提示 "已掃描，請在手機端點擊確認"

  3. 用戶在手機端點擊確認，確認後 PC 端登錄就成功了

可以看到，二維碼在中間有三個狀態， 待掃描，已掃描待確認，已確認。那麼可以想象

  1. 二維碼的背後它一定存在一個唯一性的 ID，當二維碼生成時，這個 ID 也一起生成，並且綁定了 PC 端的設備信息

  2. 手機去掃描這個二維碼

  3. 二維碼切換爲 已掃描待確認狀態， 此時就會將賬號信息與這個 ID 綁定

  4. 當手機端確認登錄時，它就會生成 PC 端用於登錄的 token，並返回給 PC 端

好了，到這裏，基本思路就已經清晰了，接下來我們把整個過程再具體化一下

二維碼準備

按二維碼不同狀態來看， 首先是等待掃描狀態，用戶打開 PC 端，切換到二維碼登錄界面時。

  1. PC 端向服務端發起請求，告訴服務端，我要生成用戶登錄的二維碼，並且把 PC 端設備信息也傳遞給服務端

  2. 服務端收到請求後，它生成二維碼 ID，並將二維碼 ID 與 PC 端設備信息進行綁定

  3. 然後把二維碼 ID 返回給 PC 端

  4. PC 端收到二維碼 ID 後，生成二維碼 (二維碼中肯定包含了 ID)

  5. 爲了及時知道二維碼的狀態，客戶端在展現二維碼後，PC 端不斷的輪詢服務端，比如每隔一秒就輪詢一次，請求服務端告訴當前二維碼的狀態及相關信息

二維碼已經準好了，接下來就是掃描狀態

掃描狀態切換

  1. 用戶用手機去掃描 PC 端的二維碼，通過二維碼內容取到其中的二維碼 ID

  2. 再調用服務端 API 將移動端的身份信息與二維碼 ID 一起發送給服務端

  3. 服務端接收到後，它可以將身份信息與二維碼 ID 進行綁定，生成臨時 token。然後返回給手機端

  4. 因爲 PC 端一直在輪詢二維碼狀態，所以這時候二維碼狀態發生了改變，它就可以在界面上把二維碼狀態更新爲已掃描

那麼爲什麼需要返回給手機端一個臨時 token 呢？臨時 token 與 token 一樣，它也是一種身份憑證，不同的地方在於它只能用一次，用過就失效。

在第三步驟中返回臨時 token，爲的就是手機端在下一步操作時，可以用它作爲憑證。以此確保掃碼，登錄兩步操作是同一部手機端發出的，

狀態確認

最後就是狀態的確認了。

  1. 手機端在接收到臨時 token 後會彈出確認登錄界面，用戶點擊確認時，手機端攜帶臨時 token 用來調用服務端的接口，告訴服務端，我已經確認

  2. 服務端收到確認後，根據二維碼 ID 綁定的設備信息與賬號信息，生成用戶 PC 端登錄的 token

  3. 這時候 PC 端的輪詢接口，它就可以得知二維碼的狀態已經變成了 "已確認"。並且從服務端可以獲取到用戶登錄的 token

  4. 到這裏，登錄就成功了，後端 PC 端就可以用 token 去訪問服務端的資源了

掃碼動作的基礎流程都講完了，有些細節還沒有深入介紹，

比如二維碼的內容是什麼？

在掃碼確認這一步，用戶取消了怎麼處理？這些細節都留給大家思考

總結

我們從登陸的本質觸發，探索二維碼掃碼登錄是如何做到的

  1. 告訴系統我是誰

  2. 向系統證明我誰

在這個過程中，我們先簡單講了兩個前提知識，

然後我們以二維碼狀態爲軸，分析了這背後的邏輯: 通過 token 認證機制與二維碼狀態變化來實現掃碼登錄.

需要指出的是，前面的講的登錄流程，它適用於同一個系統的 PC 端，WEB 端，移動端。

平時我們還有另外一種場景也比較常見，那就是通過第三方應用來掃碼登錄，那麼這種通過第三方應用掃碼登錄又是什麼原理呢？

轉自：大古同學

https://juejin.cn/post/6940976355097985032

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/FDs6YRn_1FYDLlpm7Z-q7A

猜你喜歡