用戶系統(下)第三方授權、賬號綁定與解綁

－－－－－－－－－－－－想跳過上篇問題回復可直接下滑－－－－－－－－－－－－

之前總結了用戶系統登錄和註冊及帳號打通的問題。有兩個問題大家爭議得比較多，第一是為什麼不完全打通，為什麼每一個app要保留自己的用戶資料和綁定關係；第二就是不應該用手機號作為唯一的識別方式。先說一下第一個是否完全打通的問題，取決於同一個開發者的app是否需要或者能夠讓用戶感知到這些app都是屬於同一個開發者的，很容易讓用戶感知到「哦，這些都是一家公司的」，那麼完全打通，用戶信息、綁定關係是通的用戶是完全有預期的，這是可以的。並且完全打通對於開發來說可以說得上是一個一勞永逸的事情，之後的app用戶系統這一塊可以說沒有開發量，直接接入。我們可以簡單歸納一下現在主流的用戶系統服務端設計：

1、app級的用戶系統，根據手機號郵箱註冊或第三方授權創建用戶身份，用戶的身份信息、賬號綁定、個人資料都保存在app服務端也只對單一app有效；普遍中小app都是採用的此種。

2、公司級用戶系統，根據手機號郵箱註冊創建用戶身份，用戶的身份信息、賬號綁定、個人資料都保存在統一的公司用戶系統服務端，對接入的app有效，app端有讀取修改許可權；

3、平台級用戶系統，根據手機號郵箱註冊創建用戶身份，用戶的身份信息、賬號綁定、個人資料都保存在統一的公司用戶系統服務端，選擇極少信息提供公開介面，接入的app只有讀取許可權；例如qq微博微信等第三方授權。

其他兩個不展開，關於公司級用戶系統可以舉兩個典型的例子，感興趣的朋友可以體驗一下，第一個是網易第二個是百度。大家可以回顧一下兩個公司的常用app。就我而言，網易是雲音樂、考拉海購、網易有錢等，百度是百度地圖、百度糯米。可以再去多去下載幾個體驗。網易公司的用戶系統是網易郵箱去承載，但是承擔的功能僅是提供一個用戶身份即unionID，用戶的資料、帳號、第三方登錄等都是app自己去實現的；百度公司的用戶系統是百度賬號去承載，承擔的功能除了提供用戶身份unionID外，用戶資料、第三方登錄都是保存在用戶系統的，app端有修改許可權用戶系統資料；兩家的用戶系統都沒做賬號綁定的事情，我認為原因可能是他們建立用戶系統的時候還不存在繁瑣的賬號綁定，後期想加上牽扯到新老賬號的數據合併問題是很頭疼的問題。而關於用戶資料是存在app端還是用戶系統，網易是存在app端，百度是存在用戶系統，這兩家公司區別的原因我分析有二，1）百度系app本身是偏工具的，瀏覽器、地圖、網盤等等對於用戶資料和個人中心沒有太多的定製化需求只需要基本的頭像昵稱即可，所以將用戶資料這塊保存在用戶系統，app端基本直接接入即可；網易類是比較重用戶資料和個人中心一點的，簡單的通用的並且是同步到所有app的設計是無法滿足各app產品的，所以選擇自建。包括百度需要有稍強一點的用戶資料的app（例如百度音樂）都會在用戶系統的基礎上在app端去自建和完善用戶資料。

第二個問題即不能將手機作為唯一標識的擔心實際是1、用戶手機號更換後無法找回密碼；2、舊手機號碼被重新激活後賬號信息泄露。這個問題實際上需要的是安全驗證。一般有以下方法：1）賬號綁定與解綁；2）設置安全問題；3）app用戶行為驗證；4）賬號申訴。所以只要做好安全驗證問題用手機號做為唯一標識也沒有問題，當然第二個問題事關運營商，查了下資料作為互聯網服務商上技術上是無解的，只能儘可能提醒用戶綁定與解綁手機。

－－－－－－－－－－－－－回答遺留問題的分割線－－－－－－－－－－－－－

繼續補充第三方授權登錄和賬號綁定與解綁。

（二）第三方授權登錄

上篇文章我們介紹過第三方授權的用戶不是用戶系統的用戶，僅是單一app的用戶，此原則在此篇仍適用。第三方授權是為app註冊登錄提供一種便捷的方式和補充。那麼第三方授權的登錄和註冊是怎麼回事呢？簡單來說就是第三方有一個公開的授權介面，你有權訪問並起用戶確認後能夠返回此用戶在第三方的身份openid，可作為app生成自己用戶身份的驗證。

1.主流程圖

調取第三方sdk，查詢此openid是否已有appuserid；

若是，登陸；若否，創建appuserid並將基本資料存入app服務端；

（三）賬號綁定

賬號綁定分為綁定手機號和綁定第三方授權賬號。第三方授權能夠給用戶提供便捷的註冊和登錄方式，這是好的一點，但是正因為操作太便捷沒有參與感所以用戶很容易忘記自己的登錄方式。賬號綁定到目的就是避免用戶忘記登錄方式，每次授權都在app內創建一個用戶身份，不利於用戶操作的同時也不利於產品用戶信息留存。所以產品設計上來講用戶的登錄和註冊方式盡量簡單、多種，但是盡量在非必要非用戶自主想創建另外賬號的情況下盡量一個用戶在一個app只存在一個身份。

1.主流程圖

綁定手機號

Step1：用戶輸入手機號點擊獲取驗證碼，客戶端進行基本判斷（後面詳細介紹）後，app服務端發送驗證碼；

Step2：用戶系統服務端驗證用戶的手機號是否已存在對應的appuserid；

若是，提示此號已綁定，先更換綁定手機號

若否，用戶系統按照手機號註冊流程，用戶系統創建unionid，將union傳給app並關聯當前登陸的appuserid，綁定成功

綁定第三方授權

App服務端查詢賬號信息，是否存在appuserid；

若是，提示此號已綁定，建議先解綁；

若否，將此第三方授權openid綁定到登陸的appuserid中；綁定成功

（四）賬號解綁

賬號解綁也分為手機號和第三方授權。手機號只允許更換綁定不允許解除綁定。更換綁定的場景就在於用戶更換了手機號，為了賬號安全將之前的信息遷移到新的手機號中，並將更換的原手機號從系統中刪除，若再次註冊將視為新賬號。

1.主流程圖

更綁手機號

Step1：原手機號+驗證碼，app服務端驗證是否為真，為真發送驗證碼；

Step2：新手機號+驗證碼+密碼，app服務端驗證手機號+驗證碼是否為真，為真進行step3

Step3：用戶系統服務驗證此手機號是否已存在unionid；

若是，提示更綁失敗

若否，將新手機號替換原手機號，關聯原手機號unionid，appuserid；並將原手機號從用戶系統中刪除；

解綁第三方授權

Step1：當前第三方授權是否已經綁定手機號，若是，成功解綁；若否進行step2；

Step2：當前第三方授權是否綁定其他第三方授權登陸，若是進行step3，若否提示無法解綁，首先請綁定手機號；

Step3：當前第三方授權是否為最早一個綁定（即註冊賬號）；

若是，調取第三方授權登陸頁面，用戶重新登陸要解綁賬號+密碼（需要確認是否能抹除用戶登錄信息要求輸入賬號密碼），登陸成功則解綁成功；

ps：這裡被開發同事驗證不能抹去登錄信息，因為我們只有調取介面的許可權。但是當時之所以想要這麼設計，是為了賬號安全，可以試想一個場景，我把你的賬號綁定到我的微信／微博等，然後接觸你的賬號，相當於這個賬號就歸我了。－－事實證明現在的許可權沒辦法解決這個問題。

若否，解綁成功；