今年 2 月，微信團(tuán)隊針對小程序登錄和用戶信息獲取進(jìn)行了一次接口調(diào)整，這一舉動史無前例地撼動了幾乎所有小程序開發(fā)者，在小程序社區(qū)產(chǎn)生了不小的反響。

作為接入方，本文將從產(chǎn)品和技術(shù)兩個角度，討論微信新授權(quán)登錄機(jī)制的設(shè)計目的、適配方案以及對產(chǎn)品帶來的影響。

歷史淵源：授權(quán)、登錄與獲取用戶信息

在微信問世之前，來自 Twitter 的 OAuth 模型就已經(jīng)足夠普及。在 OAuth 模型中，B 業(yè)務(wù)想要操作用戶在 A 業(yè)務(wù)中的數(shù)據(jù)，需要首先跳轉(zhuǎn)到 A 業(yè)務(wù)的頁面，讓用戶直接與 A 業(yè)務(wù)進(jìn)行確認(rèn)，稱為授權(quán)（Authorization），得到 A 業(yè)務(wù)頒發(fā)給 B 業(yè)務(wù)的「兌換碼」（一般稱為 code），并回跳到 B 業(yè)務(wù)；之后，B 業(yè)務(wù)使用這個兌換碼，通過后端直接聯(lián)系 A 業(yè)務(wù)，一次性獲得用于操作 A 業(yè)務(wù)數(shù)據(jù)的一系列憑證，并進(jìn)行保存，后續(xù)則可以使用這些憑證調(diào)用 A 業(yè)務(wù)中的操作。

在 OAuth 模型中，Auth 這一縮寫代表了兩層含義：「授權(quán)（Authorization）」指用戶直接聯(lián)系 A 業(yè)務(wù)，對操作進(jìn)行確認(rèn)的過程；而「驗證（Authentication）」則多指 A 業(yè)務(wù)對 B 業(yè)務(wù)的訪問權(quán)進(jìn)行校驗的后續(xù)流程。

微信公眾號網(wǎng)頁開發(fā)實現(xiàn)了這一模型：

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

對于登錄，其本質(zhì)是區(qū)分用戶、頒發(fā)登錄態(tài)。OpenID/UnionID 代表了用戶在微信的身份信息，讓業(yè)務(wù)后端能夠區(qū)分相同和不同的用戶，業(yè)務(wù)后端可以針對相同的用戶頒發(fā)已有的登錄態(tài)信息，訪問同一個用戶之前產(chǎn)生的數(shù)據(jù)；針對不同的用戶，則可以創(chuàng)建新的帳號信息，下發(fā)新的登錄態(tài)等；

對于獲取用戶信息，后端可以用 access_token 向微信請求獲得。

小程序老授權(quán)登錄

在微信小程序中，由于微信客戶端擁有控制力，第三方業(yè)務(wù)與微信之間不再需要跳轉(zhuǎn)，只要調(diào)用微信提供的接口，微信客戶端可以保證授權(quán)的有效性，因此授權(quán)登錄相比網(wǎng)頁開發(fā)較為簡單，但這同時也意味著微信隨時可以改變接口的行為。直到目前，小程序授權(quán)登錄的行為發(fā)生過兩次改動：

小程序剛推出時，微信提供了 wx.login 和 wx.getUserInfo 兩個接口，分別用于登錄和授權(quán)獲取用戶信息；其中 wx.login 是靜默的，會直接返回可換取 OpenID 的 code 和用于解密數(shù)據(jù)的 session_key；wx.getUserInfo 會彈出授權(quán)彈窗，經(jīng)過授權(quán)后，會返回加密的用戶數(shù)據(jù)，可以由后端憑 session_key 進(jìn)行解密。加密的目的是為了防止用戶篡改信息，從而限制違規(guī)頭像昵稱的產(chǎn)生，這一點(diǎn)不在本文的討論范圍內(nèi)。

此后不久，wx.getUserInfo 被改為不再主動彈出授權(quán)，而是會在未授權(quán)情況下靜默失敗；授權(quán)則需要使用微信提供的專門 button 組件進(jìn)行觸發(fā)，這是為了遏止部分小程序一啟動就彈出授權(quán)，或在本來不需要用戶信息的情況下超標(biāo)獲取的問題。對于一些使用 WebView 的小程序，由于 WebView 頁面中無法承載原生的 button 組件，這次改動就需要使用一個原生的授權(quán)頁面來適配。

老的這一套授權(quán)登錄流程雖然有它繁瑣的地方，但長久以來，我們都忘記了其中最大的一個方便點(diǎn)：經(jīng)過一次授權(quán)之后，小程序可以隨時靜默獲取用戶的信息。當(dāng)用戶更改了昵稱或頭像，只要打開已授權(quán)的小程序，小程序就能直接獲取到修改后的信息，而無需用戶再次授權(quán)。

新授權(quán)登錄的產(chǎn)品形態(tài)

從官方文檔中可以看出，小程序授權(quán)登錄機(jī)制調(diào)整后，主要存在兩個改動點(diǎn)：

1. 在 wx.login 接口中，現(xiàn)在可以直接獲取到用戶的 UnionID，而無需通過授權(quán)獲得，這其實是修復(fù)了之前的 Bug，同時鼓勵各小程序業(yè)務(wù)盡可能不超標(biāo)獲取用戶信息，遵循權(quán)限最小化原則；
2. 新增了 wx.getUserProfile 接口，代替原來的 wx.getUserInfo，新的接口會主動彈出授權(quán)，但只能一次性獲取當(dāng)前的昵稱頭像，而且仍然需要在用戶點(diǎn)擊后調(diào)用。

從產(chǎn)品角度而言，這兩點(diǎn)分別帶來了不同的變化：

第一點(diǎn)對于需要獲取 UnionID 的業(yè)務(wù)來說，可以讓靜默登錄的能力真正可用?？梢宰層脩粼诓皇跈?quán)昵稱頭像的情況下，使用盡可能多的功能，在需要時才提示授權(quán)，對于產(chǎn)品本身登錄過程的轉(zhuǎn)化率有很大幫助，同時也幫助微信保護(hù)用戶隱私，是一個雙贏的舉措；

而第二點(diǎn)變化則可以看作是微信對用戶信息匿名化的一個嘗試。在此之前，微信推出了自定義昵稱頭像的功能，可以在授權(quán)時設(shè)置自定義的昵稱頭像，區(qū)別于微信本身的昵稱頭像，實現(xiàn)一定的匿名使用；但由于老授權(quán)登錄接口是一次授權(quán)，用戶一旦設(shè)置了自定義的昵稱頭像就無法修改。因此，為了能將一次授權(quán)改為每次授權(quán)，微信通過新增一個接口，讓開發(fā)者對這一行為進(jìn)行主動適配。

根據(jù)微信的要求，4 月 13 日之后，新發(fā)布的版本在支持 wx.getUserProfile 的情況下，不能再使用 wx.getUserInfo，否則將收到默認(rèn)的昵稱頭像。從微信開發(fā)者工具中也可以提前看到這一改動：獲取到的頭像會變成一張默認(rèn)頭像，昵稱變?yōu)椤肝⑿庞脩簟埂?/p>

而適配這個接口也意味著產(chǎn)品交互需要發(fā)生改變，因為在此之后，一次授權(quán)只能獲得一次性的昵稱和頭像，當(dāng)用戶對微信昵稱頭像進(jìn)行了修改，小程序業(yè)務(wù)不但不能靜默獲取到修改后的昵稱頭像，完全無從得知頭像昵稱發(fā)生了變化，都必須通過重新授權(quán)才能實現(xiàn)。

對于本來需要獲取用戶昵稱頭像的小程序業(yè)務(wù)，我們探討了一種比較合理的適配方式：模擬原來的一次授權(quán)、并且提供手動修改頭像昵稱的入口。通過對登錄邏輯的改造，可以實現(xiàn)盡可能模擬原有的授權(quán)交互，只在首次使用時進(jìn)行授權(quán)，但經(jīng)過這一次授權(quán)后，昵稱頭像不會再更新；因此需要提供手動修改頭像昵稱的入口，讓用戶對「頭像昵稱不會自動同步、可以手動更新或修改」的行為有預(yù)期。

技術(shù)適配方案：以文檔小程序為例

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

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

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

1. 前端調(diào)用 wx.login，得到 code，并調(diào)用后端登錄接口，得到提前頒發(fā)的登錄態(tài)；
2. 前端調(diào)用現(xiàn)有的獲取業(yè)務(wù)用戶信息接口，判斷業(yè)務(wù)是否已獲得昵稱頭像，如果已有昵稱頭像，直接保存 1 中的登錄態(tài)，登錄完成；
3. 如果還未獲得昵稱頭像，則彈出授權(quán)，授權(quán)后調(diào)用后端上傳昵稱頭像接口，將得到的昵稱頭像進(jìn)行保存；
4. 根據(jù)產(chǎn)品交互設(shè)計，在用戶選擇更新昵稱頭像時，重復(fù) 3 中的步驟，授權(quán)并更新昵稱頭像。

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

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

總結(jié)

本文探討了微信小程序新的授權(quán)登錄機(jī)制。新的機(jī)制下，授權(quán)被局限于獲取用戶信息的一次性操作之內(nèi)，從而在鼓勵開發(fā)者盡可能少要求授權(quán)的同時，讓用戶隱私得到一定程度的保護(hù)。對于產(chǎn)品形態(tài)而言，這要求產(chǎn)品在交互上強(qiáng)化用戶頭像昵稱的可定制性；從開發(fā)角度，則需要根據(jù)具體業(yè)務(wù)情況，投入一定的精力進(jìn)行適配。

與此同時，我們也能看出在小程序授權(quán)登錄內(nèi)外的一些細(xì)節(jié)問題：接口頻繁變動、適配期限太匆忙，會導(dǎo)致開發(fā)者疲于適配，對平臺產(chǎn)生消極情緒；另外，比起頭像昵稱這些常規(guī)信息的定制，真正屬于用戶隱私的手機(jī)號碼、實名身份等信息仍然需要更嚴(yán)格的管控，才能在隱私安全的方向上走得更遠(yuǎn)。

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

文章來源：AlloyTeam_http://www.alloyteam.com/2021/04/15431/