今年 2 月，微信團隊針對小程序登錄和(hé / huò)用戶信息獲取進行了(le／liǎo)一次 接口調整 ，這(zhè)一舉動史無前例地(dì / de)撼動了(le／liǎo)幾乎所有小程序開發者，在(zài)小程序社區産生了(le／liǎo)不(bù)小的(de)反響。

作爲(wéi / wèi)接入方，本文将從産品和(hé / huò)技術兩個(gè)角度，讨論微信新授權登錄機制的(de)設計目的(de)、适配方案以(yǐ)及對産品帶來(lái)的(de)影響。

曆史淵源：授權、登錄與獲取用戶信息

在(zài)微信問世之(zhī)前，來(lái)自 Twitter 的(de) OAuth 模型就(jiù)已經足夠普及。在(zài) OAuth 模型中，B 業務想要(yào / yāo)操作用戶在(zài) A 業務中的(de)數據，需要(yào / yāo)首先跳轉到(dào) A 業務的(de)頁面，讓用戶直接與 A 業務進行确認，稱爲(wéi / wèi)授權（Authorization），得到(dào) A 業務頒發給 B 業務的(de)「兌換碼」（一般稱爲(wéi / wèi) code），并回跳到(dào) B 業務；之(zhī)後，B 業務使用這(zhè)個(gè)兌換碼，通過後端直接聯系 A 業務，一次性獲得用于(yú)操作 A 業務數據的(de)一系列憑證，并進行保存，後續則可以(yǐ)使用這(zhè)些憑證調用 A 業務中的(de)操作。

在(zài) OAuth 模型中，Auth 這(zhè)一縮寫代表了(le／liǎo)兩層含義：「授權（Authorization）」指用戶直接聯系 A 業務，對操作進行确認的(de)過程；而(ér)「驗證（Authentication）」則多指 A 業務對 B 業務的(de)訪問權進行校驗的(de)後續流程。

微信公衆号網頁開發實現了(le／liǎo)這(zhè)一模型：

對于(yú) 授權 ，公衆号網頁需要(yào / yāo)先跳轉到(dào)微信提供的(de)授權頁面，由用戶點擊确認授權（如果無需獲取用戶信息，或用戶已經授權，或已經關注過服務号，則無需确認，但仍然需要(yào / yāo)進行這(zhè)一次跳轉），授權頁面會回跳到(dào)公衆号網頁業務，并帶上(shàng) code 到(dào)網頁參數；之(zhī)後，業務方則需要(yào / yāo)通過 後端攔截 或 前端 Ajax 請求 等方式，經由業務自己的(de)後端換取微信頒發的(de) OpenID/UnionID 以(yǐ)及一個(gè) access_token 憑證；

對于(yú) 登錄 ，其本質是(shì)區分用戶、頒發登錄态。OpenID/UnionID 代表了(le／liǎo)用戶在(zài)微信的(de)身份信息，讓業務後端能夠區分相同和(hé / huò)不(bù)同的(de)用戶，業務後端可以(yǐ)針對相同的(de)用戶頒發已有的(de)登錄态信息，訪問同一個(gè)用戶之(zhī)前産生的(de)數據；針對不(bù)同的(de)用戶，則可以(yǐ)創建新的(de)帳号信息，下發新的(de)登錄态等；

對于(yú) 獲取用戶信息 ，後端可以(yǐ)用 access_token 向微信請求獲得。

小程序老授權登錄

在(zài)微信小程序中，由于(yú)微信客戶端擁有控制力，第三方業務與微信之(zhī)間不(bù)再需要(yào / yāo)跳轉，隻要(yào / yāo)調用微信提供的(de)接口，微信客戶端可以(yǐ)保證授權的(de)有效性，因此授權登錄相比網頁開發較爲(wéi / wèi)簡單，但這(zhè)同時(shí)也(yě)意味着微信随時(shí)可以(yǐ)改變接口的(de)行爲(wéi / wèi)。直到(dào)目前，小程序授權登錄的(de)行爲(wéi / wèi)發生過兩次改動：

小程序剛推出(chū)時(shí)，微信提供了(le／liǎo) wx.login 和(hé / huò) wx.getUserInfo 兩個(gè)接口，分别用于(yú) 登錄 和(hé / huò) 授權獲取用戶信息 ；其中 wx.login 是(shì)靜默的(de)，會直接返回可換取 OpenID 的(de) code 和(hé / huò)用于(yú)解密數據的(de) session_key； wx.getUserInfo 會彈出(chū)授權彈窗，經過授權後，會返回加密的(de)用戶數據，可以(yǐ)由後端憑 session_key 進行解密。加密的(de)目的(de)是(shì)爲(wéi / wèi)了(le／liǎo)防止用戶篡改信息，從而(ér)限制違規頭像昵稱的(de)産生，這(zhè)一點不(bù)在(zài)本文的(de)讨論範圍内。

此後不(bù)久， wx.getUserInfo 被改爲(wéi / wèi)不(bù)再主動彈出(chū)授權，而(ér)是(shì)會在(zài)未授權情況下靜默失敗；授權則需要(yào / yāo)使用微信提供的(de)專門 button 組件進行觸發，這(zhè)是(shì)爲(wéi / wèi)了(le／liǎo)遏止部分小程序一啓動就(jiù)彈出(chū)授權，或在(zài)本來(lái)不(bù)需要(yào / yāo)用戶信息的(de)情況下超标獲取的(de)問題。對于(yú)一些使用 WebView 的(de)小程序，由于(yú) WebView 頁面中無法承載原生的(de) button 組件，這(zhè)次改動就(jiù)需要(yào / yāo)使用一個(gè)原生的(de)授權頁面來(lái)适配。

老的(de)這(zhè)一套授權登錄流程雖然有它繁瑣的(de)地(dì / de)方，但長久以(yǐ)來(lái)，我們都忘記了(le／liǎo)其中最大(dà)的(de)一個(gè)方便點： 經過一次授權之(zhī)後，小程序可以(yǐ)随時(shí)靜默獲取用戶的(de)信息。 當用戶更改了(le／liǎo)昵稱或頭像，隻要(yào / yāo)打開已授權的(de)小程序，小程序就(jiù)能直接獲取到(dào)修改後的(de)信息，而(ér)無需用戶再次授權。

新授權登錄的(de)産品形态

從官方文檔中可以(yǐ)看出(chū)，小程序授權登錄機制調整後，主要(yào / yāo)存在(zài)兩個(gè)改動點：

1. 在(zài) wx.login 接口中，現在(zài)可以(yǐ)直接獲取到(dào)用戶的(de) UnionID，而(ér)無需通過授權獲得，這(zhè)其實是(shì)修複了(le／liǎo)之(zhī)前的(de) Bug，同時(shí)鼓勵各小程序業務盡可能不(bù)超标獲取用戶信息，遵循權限最小化原則；
2. 新增了(le／liǎo) wx.getUserProfile 接口，代替原來(lái)的(de) wx.getUserInfo ，新的(de)接口會主動彈出(chū)授權，但隻能一次性獲取當前的(de)昵稱頭像，而(ér)且仍然需要(yào / yāo)在(zài)用戶點擊後調用。

從産品角度而(ér)言，這(zhè)兩點分别帶來(lái)了(le／liǎo)不(bù)同的(de)變化：

第一點對于(yú)需要(yào / yāo)獲取 UnionID 的(de)業務來(lái)說(shuō)，可以(yǐ)讓靜默登錄的(de)能力真正可用。可以(yǐ)讓用戶在(zài)不(bù)授權昵稱頭像的(de)情況下，使用盡可能多的(de)功能，在(zài)需要(yào / yāo)時(shí)才提示授權，對于(yú)産品本身登錄過程的(de)轉化率有很大(dà)幫助，同時(shí)也(yě)幫助微信保護用戶隐私，是(shì)一個(gè)雙赢的(de)舉措；

而(ér)第二點變化則可以(yǐ)看作是(shì)微信對用戶信息匿名化的(de)一個(gè)嘗試。在(zài)此之(zhī)前，微信推出(chū)了(le／liǎo)自定義昵稱頭像的(de)功能，可以(yǐ)在(zài)授權時(shí)設置自定義的(de)昵稱頭像，區别于(yú)微信本身的(de)昵稱頭像，實現一定的(de)匿名使用；但由于(yú)老授權登錄接口是(shì)一次授權，用戶一旦設置了(le／liǎo)自定義的(de)昵稱頭像就(jiù)無法修改。因此，爲(wéi / wèi)了(le／liǎo)能将一次授權改爲(wéi / wèi)每次授權，微信通過新增一個(gè)接口，讓開發者對這(zhè)一行爲(wéi / wèi)進行主動适配。

根據微信的(de)要(yào / yāo)求，4 月 13 日之(zhī)後，新發布的(de)版本在(zài)支持 wx.getUserProfile 的(de)情況下，不(bù)能再使用 wx.getUserInfo ，否則将收到(dào)默認的(de)昵稱頭像。從微信開發者工具中也(yě)可以(yǐ)提前看到(dào)這(zhè)一改動：獲取到(dào)的(de)頭像會變成一張默認頭像，昵稱變爲(wéi / wèi)「微信用戶」。

而(ér)适配這(zhè)個(gè)接口也(yě)意味着産品交互需要(yào / yāo)發生改變，因爲(wéi / wèi)在(zài)此之(zhī)後，一次授權隻能獲得一次性的(de)昵稱和(hé / huò)頭像，當用戶對微信昵稱頭像進行了(le／liǎo)修改，小程序業務不(bù)但不(bù)能靜默獲取到(dào)修改後的(de)昵稱頭像，完全無從得知頭像昵稱發生了(le／liǎo)變化，都必須通過重新授權才能實現。

對于(yú)本來(lái)需要(yào / yāo)獲取用戶昵稱頭像的(de)小程序業務，我們探讨了(le／liǎo)一種比較合理的(de)适配方式： 模拟原來(lái)的(de)一次授權 、并且 提供手動修改頭像昵稱的(de)入口 。通過對登錄邏輯的(de)改造，可以(yǐ)實現盡可能模拟原有的(de)授權交互，隻在(zài)首次使用時(shí)進行授權，但經過這(zhè)一次授權後，昵稱頭像不(bù)會再更新；因此需要(yào / yāo)提供手動修改頭像昵稱的(de)入口，讓用戶對「頭像昵稱不(bù)會自動同步、可以(yǐ)手動更新或修改」的(de)行爲(wéi / wèi)有預期。

技術适配方案：以(yǐ)文檔小程序爲(wéi / wèi)例

在(zài)文檔小程序中，原有的(de)登錄接口是(shì)二合一的(de)，即前端先調用完 wx.login 和(hé / huò) wx.getUserInfo ，得到(dào) code 和(hé / huò)加密的(de)用戶信息，然後一起調用後端接口，後端查詢已有用戶或創建新用戶，并對用戶頭像昵稱信息進行更新。

在(zài)新授權登錄的(de)背景下，這(zhè)樣的(de)後端接口已經無法滿足要(yào / yāo)求。爲(wéi / wèi)了(le／liǎo)盡可能還原原有的(de)一次授權交互，我們需要(yào / yāo)先判斷用戶是(shì)否已授權，然後根據是(shì)否已有昵稱頭像，決定是(shì)否調用授權并上(shàng)傳用戶的(de)昵稱頭像。另外，在(zài)用戶選擇手動更新昵稱頭像時(shí)，也(yě)需要(yào / yāo)有接口負責上(shàng)傳更新用戶的(de)昵稱頭像。

因此，爲(wéi / wèi)了(le／liǎo)保持接口設計的(de)合理性，我們将登錄接口拆分成兩個(gè)接口，并搭配獲取業務用戶信息的(de)接口進行實現：

wx.login

由于(yú) wx.getUserProfile 隻返回了(le／liǎo)明文的(de)昵稱頭像等信息，我們還需要(yào / yāo)對上(shàng)傳昵稱頭像的(de)接口接入内容安全保護，防止用戶任意上(shàng)傳不(bù)合規的(de)昵稱頭像信息。

除此之(zhī)外，在(zài) QQ 小程序以(yǐ)及 PC/Mac 微信小程序的(de)情況下，新的(de)授權登錄接口可能并沒有支持，需要(yào / yāo)對不(bù)支持 wx.getUserProfile 接口的(de)情況進行兼容，改用原有的(de)授權登錄邏輯。

總結

本文探讨了(le／liǎo)微信小程序新的(de)授權登錄機制。新的(de)機制下，授權被局限于(yú)獲取用戶信息的(de)一次性操作之(zhī)内，從而(ér)在(zài)鼓勵開發者盡可能少要(yào / yāo)求授權的(de)同時(shí)，讓用戶隐私得到(dào)一定程度的(de)保護。對于(yú)産品形态而(ér)言，這(zhè)要(yào / yāo)求産品在(zài)交互上(shàng)強化用戶頭像昵稱的(de)可定制性；從開發角度，則需要(yào / yāo)根據具體業務情況，投入一定的(de)精力進行适配。

與此同時(shí)，我們也(yě)能看出(chū)在(zài)小程序授權登錄内外的(de)一些細節問題：接口頻繁變動、适配期限太匆忙，會導緻開發者疲于(yú)适配，對平台産生消極情緒；另外，比起頭像昵稱這(zhè)些常規信息的(de)定制，真正屬于(yú)用戶隐私的(de)手機号碼、實名身份等信息仍然需要(yào / yāo)更嚴格的(de)管控，才能在(zài)隐私安全的(de)方向上(shàng)走得更遠。

小程序是(shì)一個(gè)爲(wéi / wèi)控制力而(ér)生的(de)平台，但我們更希望這(zhè)樣的(de)控制力去約束不(bù)守規矩的(de)開發者，管住一味營銷、缺乏實用性的(de)産品，放手讓用心打磨的(de)項目走得更遠。