本文引用了作者“大古同學”的“二維碼掃碼登錄是什麼原理”一文的主要內容，爲了更好的理解和閱讀，即時通訊網收錄時有修訂和改動，感謝原作者的分享。
1、引言
自從微信的PC端使用掃碼登陸認證邏輯後，這種方式似乎在越來越多的IM中看到（雖然我個人認爲這種登錄方式很酷，但並不方便，尤其手機不大身邊的時候）。
最近剛好看到一個二維碼的技術原理講解視頻，正好藉此機會將掃碼登錄的詳細技術原理梳理並總結一下，方便自已回顧，也希望能幫助到想在IM裏開發類似功能的同行們。
補充說明：本文所涉及的掃碼登陸原理並不是僅僅針對IM系統，同樣適用於IM之外的其它系統。
2、專題目錄
本文是系列文章的第3篇，總目錄如下：
《IM掃碼登錄技術專題(一)：微信的掃碼登錄功能技術原理調試分析》
3、二維碼登錄的本質
3.1 掃碼登錄安全嗎？
在2維碼掃碼登錄的過程中，大家可能會有疑問：這二維碼安全嗎？會不會泄漏我的個人信息？我的im系統敢不敢也搞一個掃碼登錄呢？
針對這些顧慮，我們需要了解一下二維碼掃碼登錄背後的技術和邏輯本質。
3.2 掃碼登錄的技術本質
二維碼掃碼登錄本質上也是一種登錄認證方式。
既然是登錄認證，要做的也就兩件事情：
- 1）告訴系統我是誰；
- 2）向系統證明我是誰。
舉個實際的例子來理解一下：
- 比如賬號密碼登錄：賬號就是告訴系統我是誰， 密碼就是向系統證明我是誰；
- 比如手機驗證碼登錄：手機號就是告訴系統我是誰，驗證碼就是向系統證明我是誰。
那麼掃碼登錄是怎麼做到這兩件事情的呢？
以微作的掃碼登錄爲例：手機端應用掃PC端二維碼，手機端確認後，賬號就在PC端登錄成功了！這裏，PC端登錄的賬號肯定與手機端是同一個賬號。不可能手機端登錄的是賬號A，而掃碼登錄以後，PC端登錄的是賬號B。
所以，第一件事情——“告訴系統我是誰”，是比較清楚的！
PS：通過掃描二維碼，把手機端的賬號信息傳遞到PC端，至於具體是怎麼傳的，我們後面再說。
第二件事情：“向系統證明我是誰”。掃碼登錄過程中，用戶並沒有去輸入密碼，也沒有輸入驗證碼，或者其他什麼碼。那是怎麼證明的呢？
有些同學會想到，是不是掃碼過程中，把密碼傳到了PC端呢？
但這是不可能的。因爲那樣太不安全的，客戶端也根本不會去存儲密碼。
我們仔細想一下，其實手機端APP它是已經登錄過的，就是說手機端是已經通過登錄認證。所說只要掃碼確認是這個手機且是這個賬號操作的，其實就能間接證明我誰。
4、認識二維碼
那麼如何做掃碼登陸的確認呢？我們後面會詳細說明，在這之前我們需要先認識一下二維碼！ 在認識二維碼之前我們先看一下一維碼！
▲ 這就是一維碼
所謂一維碼，也就是條形碼，條形碼實際上就是一串數字，以平時生活中的商品爲例，它上面的一維碼存儲的就是商品的編號。
二維碼其實與條形碼類似，只不過它存儲的不一定是數字，還可以是任何的字符串，你可以認爲，它就是字符串的另外一種表現形式。
在搜索引擎中搜索二維碼，你可以找到很多在線生成二維碼的工具網站，這些網站可以提供字符串與二維碼之間相互轉換的功能，比如 草料二維碼網站。
▲ 輸入一段字符串就能生成二維碼
在左邊的輸入框就可以輸入你的內容，它可以是文本、網址，文件........。然後就可以生成代表它們的二維碼。
▲ 這是二維碼（已經將內容模糊處理）
你也可以把二維碼上傳，進行”解碼“，然後就可以解析出二維碼代表的含義。
5、傳統系統是如何登陸認證的？
認識了二維碼，我們瞭解一下移動互聯網下的傳統登錄認證機制。
前面我們說過，爲了安全，手機端它是不會存儲你的登錄密碼的。 但是在日常使用過程中，我們應該會注意到，只有在你的應用下載下來後，第一次登錄的時候，才需要進行一個賬號密碼的登錄， 那之後呢 即使這個應用進程被殺掉，或者手機重啓，都是不需要再次輸入賬號密碼的，它可以自動登錄。
其實這背後就是一套基於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。
限於篇幅，這方面的文章，可以詳細讀一下以下幾篇：
《IM開發基礎知識補課(一)：正確理解前置HTTP SSO單點登陸接口的原理》
那麼在掃碼登錄過程中，PC端是怎麼獲得屬於自己的token呢？不可能手機端直接把自己的token給PC端用！token只能屬於某個客戶端私有，其他人或者是其他客戶端是用不了的。
在分析這個問題之前，我們有必要先梳理一下，掃描二維碼登錄的一般步驟是什麼樣的。這可以幫助我們梳理清楚整個過程。
6、掃碼登錄的詳細技術步驟
6.1 大概流程
如上圖所示：
- 1）掃碼前，手機端應用是已登錄狀態，PC端顯示一個二維碼，等待掃描；
- 2）手機端打開應用，掃描PC端的二維碼，掃描後，會提示“已掃描，請在手機端點擊確認”；
- 3）用戶在手機端點擊確認，確認後PC端登錄就成功了。
可以看到，二維碼在中間有三個狀態：待掃描、已掃描待確認、已確認。
那麼可以想象：
具體解釋就是：
- 1）二維碼的背後它一定存在一個唯一性的ID，當二維碼生成時，這個ID也一起生成，並且綁定了PC端的設備信息；
- 2）手機去掃描這個二維碼；
- 3）二維碼切換爲 已掃描待確認狀態， 此時就會將賬號信息與這個ID綁定；
- 4）當手機端確認登錄時，它就會生成PC端用於登錄的token，並返回給PC端。
好了，到這裏，基本思路就已經清晰了，接下來我們把整個過程再具體化一下。
6.2 二維碼準備
按二維碼不同狀態來看， 首先是等待掃描狀態，用戶打開PC端，切換到二維碼登錄界面時。
如上圖所示：
- 1）PC端向服務端發起請求，告訴服務端，我要生成用戶登錄的二維碼，並且把PC端設備信息也傳遞給服務端；
- 2）服務端收到請求後，它生成二維碼ID，並將二維碼ID與PC端設備信息進行綁定；
- 3）然後把二維碼ID返回給PC端；
- 4）PC端收到二維碼ID後，生成二維碼（二維碼中肯定包含了ID）；
- 5）爲了及時知道二維碼的狀態，客戶端在展現二維碼後，PC端不斷的輪詢服務端，比如每隔一秒就輪詢一次，請求服務端告訴當前二維碼的狀態及相關信息。
二維碼已經準好了，接下來就是掃描狀態。
6.3 掃描狀態切換
如上圖所示：
- 1）用戶用手機去掃描PC端的二維碼，通過二維碼內容取到其中的二維碼ID；
- 2）再調用服務端API將移動端的身份信息與二維碼ID一起發送給服務端；
- 3）服務端接收到後，它可以將身份信息與二維碼ID進行綁定，生成臨時token。然後返回給手機端；
- 4）因爲PC端一直在輪詢二維碼狀態，所以這時候二維碼狀態發生了改變，它就可以在界面上把二維碼狀態更新爲已掃描。
那麼爲什麼需要返回給手機端一個臨時token呢？
臨時token與token一樣，它也是一種身份憑證，不同的地方在於它只能用一次，用過就失效。
在上圖中的第三步驟中返回臨時token，爲的就是手機端在下一步操作時，可以用它作爲憑證。以此確保掃碼，登錄兩步操作是同一部手機端發出的。
6.4 狀態確認
最後就是狀態的確認了。
如上圖所示：
- 1）手機端在接收到臨時token後會彈出確認登錄界面，用戶點擊確認時，手機端攜帶臨時token用來調用服務端的接口，告訴服務端，我已經確認；
- 2）服務端收到確認後，根據二維碼ID綁定的設備信息與賬號信息，生成用戶PC端登錄的token；
- 3）這時候PC端的輪詢接口，它就可以得知二維碼的狀態已經變成了"已確認"。並且從服務端可以獲取到用戶登錄的token；
- 4）到這裏，登錄就成功了，後端PC端就可以用token去訪問服務端的資源了。
掃碼動作的基礎流程都講完了，有些細節還沒有深入介紹。
比如二維碼的內容是什麼？
- 1）可以是二維碼ID；
- 2）可以是包含二維碼ID的一個url地址。
在掃碼確認這一步，用戶取消了怎麼處理？ 這些細節都留給大家思考。
7、本文小結
通俗地總結一下本文的掃碼登陸邏輯就是：
掃碼登錄的本質就是：
- 1）告訴系統我是誰；
- 2）向系統證明我誰。
在這個過程中，我們先簡單講了兩個前提知識：
- 1）一個是二維碼原理；
- 2）一個是基於token的認證機制。
然後我們以二維碼狀態爲軸，分析了這背後的邏輯: 通過token認證機制與二維碼狀態變化來實現掃碼登錄。
需要指出的是，前面的講的登錄流程，它適同樣用於同一個系統的PC端，WEB端，移動端。
平時我們還有另外一種場景也比較常見，那就是通過第三方應用來掃碼登錄，比如極客時間/掘金 都可以選擇微信/QQ等掃碼登錄，那麼這種通過第三方應用掃碼登錄又是什麼原理呢？
感興趣的同學可以思考研究一下，歡迎在評論留下你的見解。
附錄：更多IM開發熱門知識
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》
《小白必讀：閒話HTTP短連接中的Session和Token》
《IM開發基礎知識補課：正確理解前置HTTP SSO單點登錄接口的原理》
《IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞》
《開源IM工程“蘑菇街TeamTalk”的現狀：一場有始無終的開源秀》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》
《騰訊原創分享(一)：如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《騰訊原創分享(三)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《基於社交網絡的Yelp是如何實現海量用戶圖片的無損壓縮的？》
《騰訊技術分享：騰訊是如何大幅降低帶寬和網絡流量的(圖片壓縮篇)》
《騰訊技術分享：騰訊是如何大幅降低帶寬和網絡流量的(音視頻技術篇)》
《字符編碼那點事：快速理解ASCII、Unicode、GBK和UTF-8》
《子彈短信光鮮的背後：網易雲信首席架構師分享億級IM平臺的技術實踐》
《IM開發基礎知識補課(五)：通俗易懂，正確理解並用好MQ消息隊列》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《自已開發IM有那麼難嗎？手把手教你自擼一個Andriod版簡易IM (有源碼)》
《IM開發基礎知識補課(六)：數據庫用NoSQL還是SQL？讀這篇就夠了！》
《適合新手：從零開發一個IM服務端（基於Netty，有完整源碼）》
《適合新手：手把手教你用Go快速搭建高性能、可擴展的IM系統(有源碼)》
《IM裏“附近的人”功能實現原理是什麼？如何高效率地實現它？》
《IM開發基礎知識補課(七)：主流移動端賬號登錄方式的原理及設計思路》
《IM開發基礎知識補課(八)：史上最通俗，徹底搞懂字符亂碼問題的本質》
《IM“掃一掃”功能很好做？看看微信“掃一掃識物”的完整技術實現》
《IM的掃碼登錄功能如何實現？一文搞懂主流應用的掃碼登錄技術原理》
《IM消息ID技術專題(一)：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《IM消息ID技術專題(二)：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》
《IM消息ID技術專題(三)：解密融雲IM產品的聊天消息ID生成策略》
《IM消息ID技術專題(四)：深度解密美團的分佈式ID生成算法》
《IM消息ID技術專題(五)：開源分佈式ID生成器UidGenerator的技術實現》
《IM消息ID技術專題(六)：深度解密滴滴的高性能ID生成器(Tinyid)》
《IM開發寶典：史上最全，微信各種功能參數和邏輯規則資料彙總》
《IM開發乾貨分享：我是如何解決大量離線消息導致客戶端卡頓的》
《零基礎IM開發入門(四)：什麼是IM系統的消息時序一致性？》
《IM開發乾貨分享：有贊移動端IM的組件化SDK架構設計實踐》
《一套億級用戶的IM架構技術乾貨(下篇)：可靠性、有序性、弱網優化等》
>> 更多同類文章 ……
本文已同步發佈於“即時通訊技術圈”公衆號。
▲ 本文在公衆號上的鏈接是：點此進入。同步發佈鏈接是：http://www.52im.net/thread-3525-1-1.html
