登錄方式的演變過程

說到一鍵登錄，我們需要先熟悉一下登錄方式的演變過程，大致可以分為四個階段。

階段一：賬號+密碼登錄

賬號+密碼登錄是傳統的登錄方式，也是早期市場上最普遍的登錄方式，用戶憑自己注冊時設置賬號和密碼在登錄時使用，雖然簡單粗暴，也確實能夠滿足用戶鑒權的場景，但缺點也是顯而易見：

(資料圖)

用戶層面：

記憶成本高：要求用戶記住自己的賬號和密碼，當用戶忘記賬戶或密碼時，就只能通過繁瑣的“找回密碼”來重新設置密碼，給用戶帶來了不佳的體驗。賬號泄漏影響面廣：用戶為了降低記憶成本，通常會在不同的平臺使用同一套賬號密碼，一旦某個平臺的賬戶密碼泄漏了，會殃及用戶使用的其他平臺。

企業層面：

惡意注冊：既不與設備綁定也不與身份綁定，意味著一個用戶可以注冊多個不同的賬號，耗費服務成本和運營成本，也影響了業務數據的準確性。

出于企業的角度，惡意注冊帶來的問題尤為明顯，為了解決這個問題需要用一個和用戶身份強相關的東西來做賬號。但是究竟用什么呢？總不能用身份證號吧，直到手機號實名制政策的發布，手機號成為我們另一個身份證明，這個問題終于得到了解決。

階段二：手機號+驗證碼

手機號+驗證碼是當前應用最廣的登錄方式，和賬號+密碼相比，它不要用戶再去記自己的賬號密碼，也增加了安全性，可以更好的驗證用戶身份并防止惡意注冊。這種方式還可以把登錄和注冊流程進行結合，若登錄時發現手機號還未注冊，則先用手機號注冊好之后再進行登錄，一切都是靜默進行，用戶無感，極大的降低了用戶的操作成本。但是這種方式依然存在缺點：

輸入成本高：需要輸入手機號 ?? 獲取并等待驗證碼短信 ?? 輸入驗證碼 ?? 點擊登錄。這套流程走完之后大概在20秒以上，操作步驟多。依賴短信：若因為異常未收到短信就登錄不成功（比如手機號被加入了黑名單，導致收不到驗證碼），造成用戶在注冊階段就流失。存在驗證碼泄漏風險：如果有人知道你的手機號，并且竊取了驗證碼，賬號就會被盜用

到這一步，一些有心人會回過頭想一下：

為什么需要驗證碼？驗證碼的作用是確認手機號是用戶本人的，那么除了驗證碼還有那些方式可以證明手機號是用戶本人的？如果能提前獲取到用戶當前使用的真實手機號，然后對用戶輸入的手機號進行驗證，是不是同樣可以證明呢？

階段三：本機號碼認證

雖然操作系統限制用戶端無法直接獲取手機號，但是運營商可以通過sim卡流量數據查詢到，因此號碼認證應運而生。

現在國內三大運營商（移動、聯通、電信）都已經開放了相關的能力：用戶輸入手機號之后請求運營商接口，運營商拿到用戶輸入的手機號并通過請求網絡流量查詢 sim 卡對應的手機號，判斷兩者是否一致，即可完成登錄，極大的簡化了登錄流程，提高了安全性。

再進一步想，既然運營商可以查詢到用戶當前使用的手機號，直接讓運營商返回用戶當前手機號碼，讓用戶直接用當前手機號碼登錄，不就可以進一步減少輸入成本，變得更加便捷嗎？于是運營商也開放了直接返回手機號的能力。

階段四：一鍵登錄

一鍵登錄簡單來講就是獲取當前用戶當前手機號，直接用該手機號進行登錄，這種登錄方式特點是一鍵式，完美解決了上述登錄方式存在記憶成本、輸入成本、泄漏風險、惡意注冊等所有問題，登錄的整個過程2秒左右，也極大程度降低了注冊登錄環節的用戶流失。

小結

一鍵登錄的基本原理

要使用一鍵登錄需要在用戶端內集成運營商的 SDK,三大運營商提供的授權流程也都是一致，下方是一鍵登錄的流程圖：

一鍵登錄流程圖

這里對一些關鍵步驟進行說明：

1.2 判斷手機號歸屬運營商：雖然用戶端不能獲取手機號，但是 ios、Android 操作系統提供了蜂窩煤網絡信息的獲取方法，可以從中解析得知用戶當前手機號歸屬哪個運營商。并且由于需要獲取手機蜂窩煤網絡信息，也就是說需要通過手機流量上網才能支持一鍵登錄。 2.1 對應運營商發起預取號：預取號的目的是獲取手機號掩碼，也就是手機號的前三后四位，如186****5385，這個手機號掩碼需要在一鍵登錄授權頁面展示給用戶看，因為預取號需要通過運營商服務端才能獲取，所以會有一定的等待時間，因此為了提升用戶體驗，可以在打開應用的的時候就去獲取，然后將其緩存下來。 3.3獲取登錄 Token ：因為手機號屬于用戶的敏感信息，運營商為滿足國家相關法律法規的規范要求，且保障用戶在知情的情況下清晰地了解并同意授權用戶端獲取該信息，因此拉起授權頁面后需要用戶勾選運營商協議。用戶確認授權一鍵登錄之后，用戶端會向運營商發起請求以獲取登錄 Token，運營商服務端會返回一個登錄 Token 給用戶端，應用再通過自己的業務服務端拿著這個 Token 找運營商換取手機號碼。 4.3返回手機號：成功返回手機號后，可以說是已經登錄成功了，應用就需要維護自己用戶的登錄狀態，這里可以采用傳統的 Session 機制，也可以使用 JWT 機制。

這里還存在一個安全問題：

4.1提交登錄 Token 到業務服務端：一些不法用戶如果偽造一個登錄 Token 向業務服務端提交請求，業務服務端再向運營商服務端發起請求，雖然這個 Token 可以最終在運營商側會被阻止，但是不免浪費資源，給服務端帶來壓力。關于這一點也有解決辦法，業務服務端先生成一個隨機數，然后用戶端向業務服務端提交時帶著這個隨機數，業務服務端驗證這個隨機數，就可以很大程度避免這個問題。