今年 2 月(yuè)，微信團隊針對小程序登錄和(hé)用戶信息獲取進行了一次 接口調整 ，這一舉動(dòng)史無前例地撼動(dòng)了幾乎所有小程序開發者，在小程序社區産生了不小的反響。

作為接入方，本文(wén)将從産品和(hé)技術(shù)兩個(gè)角度，讨論微信新授權登錄機制的設計目的、适配方案以及對産品帶來的影響。

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

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

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

微信公衆号網頁開發實現了這一模型：

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

對于 登錄 ，其本質是區分用戶、頒發登錄态。OpenID/UnionID 代表了用戶在微信的身份信息，讓業(yè)務後端能夠區分相同和(hé)不同的用戶，業(yè)務後端可(kě)以針對相同的用戶頒發已有的登錄态信息，訪問(wèn)同一個(gè)用戶之前産生的數據；針對不同的用戶，則可(kě)以創建新的帳号信息，下(xià)發新的登錄态等；

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

小程序老授權登錄

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

小程序剛推出時，微信提供了 wx.login 和(hé) wx.getUserInfo 兩個(gè)接口，分别用于 登錄 和(hé) 授權獲取用戶信息 ；其中(zhōng) wx.login 是靜默的，會直接返回可(kě)換取 OpenID 的 code 和(hé)用于解密數據的 session_key； wx.getUserInfo 會彈出授權彈窗，經過授權後，會返回加密的用戶數據，可(kě)以由後端憑 session_key 進行解密。加密的目的是為了防止用戶篡改信息，從而限制違規頭像昵稱的産生，這一點不在本文(wén)的讨論範圍内。

此後不久， wx.getUserInfo 被改為不再主動(dòng)彈出授權，而是會在未授權情況下(xià)靜默失敗；授權則需要使用微信提供的專門 button 組件進行觸發，這是為了遏止部分小程序一啟動(dòng)就彈出授權，或在本來不需要用戶信息的情況下(xià)超标獲取的問(wèn)題。對于一些使用 WebView 的小程序，由于 WebView 頁面中(zhōng)無法承載原生的 button 組件，這次改動(dòng)就需要使用一個(gè)原生的授權頁面來适配。

老的這一套授權登錄流程雖然有它繁瑣的地方，但長久以來，我們都忘記了其中(zhōng)最大的一個(gè)方便點： 經過一次授權之後，小程序可(kě)以随時靜默獲取用戶的信息。 當用戶更改了昵稱或頭像，隻要打開已授權的小程序，小程序就能直接獲取到修改後的信息，而無需用戶再次授權。

新授權登錄的産品形态

從官方文(wén)檔中(zhōng)可(kě)以看出，小程序授權登錄機制調整後，主要存在兩個(gè)改動(dòng)點：

1. 在 wx.login 接口中(zhōng)，現在可(kě)以直接獲取到用戶的 UnionID，而無需通(tōng)過授權獲得，這其實是修複了之前的 Bug，同時鼓勵各小程序業(yè)務盡可(kě)能不超标獲取用戶信息，遵循權限最小化原則；
2. 新增了 wx.getUserProfile 接口，代替原來的 wx.getUserInfo ，新的接口會主動(dòng)彈出授權，但隻能一次性獲取當前的昵稱頭像，而且仍然需要在用戶點擊後調用。

從産品角度而言，這兩點分别帶來了不同的變化：

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

而第二點變化則可(kě)以看作是微信對用戶信息匿名化的一個(gè)嘗試。在此之前，微信推出了自定義昵稱頭像的功能，可(kě)以在授權時設置自定義的昵稱頭像，區别于微信本身的昵稱頭像，實現一定的匿名使用；但由于老授權登錄接口是一次授權，用戶一旦設置了自定義的昵稱頭像就無法修改。因此，為了能将一次授權改為每次授權，微信通(tōng)過新增一個(gè)接口，讓開發者對這一行為進行主動(dòng)适配。

根據微信的要求，4 月(yuè) 13 日之後，新發布的版本在支持 wx.getUserProfile 的情況下(xià)，不能再使用 wx.getUserInfo ，否則将收到默認的昵稱頭像。從微信開發者工具中(zhōng)也可(kě)以提前看到這一改動(dòng)：獲取到的頭像會變成一張默認頭像，昵稱變為「微信用戶」。

而适配這個(gè)接口也意味着産品交互需要發生改變，因為在此之後，一次授權隻能獲得一次性的昵稱和(hé)頭像，當用戶對微信昵稱頭像進行了修改，小程序業(yè)務不但不能靜默獲取到修改後的昵稱頭像，完全無從得知頭像昵稱發生了變化，都必須通(tōng)過重新授權才能實現。

對于本來需要獲取用戶昵稱頭像的小程序業(yè)務，我們探讨了一種比較合理的适配方式： 模拟原來的一次授權 、并且 提供手動(dòng)修改頭像昵稱的入口 。通(tōng)過對登錄邏輯的改造，可(kě)以實現盡可(kě)能模拟原有的授權交互，隻在首次使用時進行授權，但經過這一次授權後，昵稱頭像不會再更新；因此需要提供手動(dòng)修改頭像昵稱的入口，讓用戶對「頭像昵稱不會自動(dòng)同步、可(kě)以手動(dòng)更新或修改」的行為有預期。

技術(shù)适配方案：以文(wén)檔小程序為例

在文(wén)檔小程序中(zhōng)，原有的登錄接口是二合一的，即前端先調用完 wx.login 和(hé) wx.getUserInfo ，得到 code 和(hé)加密的用戶信息，然後一起調用後端接口，後端查詢已有用戶或創建新用戶，并對用戶頭像昵稱信息進行更新。

在新授權登錄的背景下(xià)，這樣的後端接口已經無法滿足要求。為了盡可(kě)能還原原有的一次授權交互，我們需要先判斷用戶是否已授權，然後根據是否已有昵稱頭像，決定是否調用授權并上傳用戶的昵稱頭像。另外，在用戶選擇手動(dòng)更新昵稱頭像時，也需要有接口負責上傳更新用戶的昵稱頭像。

因此，為了保持接口設計的合理性，我們将登錄接口拆分成兩個(gè)接口，并搭配獲取業(yè)務用戶信息的接口進行實現：

wx.login

由于 wx.getUserProfile 隻返回了明文(wén)的昵稱頭像等信息，我們還需要對上傳昵稱頭像的接口接入内容安全保護，防止用戶任意上傳不合規的昵稱頭像信息。

除此之外，在 QQ 小程序以及 PC/Mac 微信小程序的情況下(xià)，新的授權登錄接口可(kě)能并沒有支持，需要對不支持 wx.getUserProfile 接口的情況進行兼容，改用原有的授權登錄邏輯。

總結

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

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

小程序是一個(gè)為控制力而生的平台，但我們更希望這樣的控制力去約束不守規矩的開發者，管住一味營銷、缺乏實用性的産品，放手讓用心打磨的項目走得更遠(yuǎn)。