走向匿名化，谈谈微信小程序新授权登录

发表时间：2021-4-22

发布人：葵宇科技

浏览次数：46

今年 2 月，微信团队针对小程序登录和用户信息获取进行了一次接口调整，这一举动史无前例地撼动了几乎所有小程序开发者，在小程序社区产生了不小的反响。

作为接入方，本文将从产品和技术两个角度，讨论微信新授权登录机制的设计目的、适配方案以及对产品带来的影响。

历史渊源：授权、登录与获取用户信息

在微信问世之前，来自 Twitter 的 OAuth 模型就已经足够普及。在 OAuth 模型中，B 业务想要操作用户在 A 业务中的数据，需要首先跳转到 A 业务的页面，让用户直接与 A 业务进行确认，称为授权（Authorization），得到 A 业务颁发给 B 业务的「兑换码」（一般称为 code），并回跳到 B 业务；之后，B 业务使用这个兑换码，通过后端直接联系 A 业务，一次性获得用于操作 A 业务数据的一系列凭证，并进行保存，后续则可以使用这些凭证调用 A 业务中的操作。

在 OAuth 模型中，Auth 这一缩写代表了两层含义：「授权（Authorization）」指用户直接联系 A 业务，对操作进行确认的过程；而「验证（Authentication）」则多指 A 业务对 B 业务的访问权进行校验的后续流程。

微信公众号网页开发实现了这一模型：

对于授权，公众号网页需要先跳转到微信提供的授权页面，由用户点击确认授权（如果无需获取用户信息，或用户已经授权，或已经关注过服务号，则无需确认，但仍然需要进行这一次跳转），授权页面会回跳到公众号网页业务，并带上 code 到网页参数；之后，业务方则需要通过 后端拦截 或 前端 Ajax 请求 等方式，经由业务自己的后端换取微信颁发的 OpenID/UnionID 以及一个 access_token 凭证；

对于登录，其本质是区分用户、颁发登录态。OpenID/UnionID 代表了用户在微信的身份信息，让业务后端能够区分相同和不同的用户，业务后端可以针对相同的用户颁发已有的登录态信息，访问同一个用户之前产生的数据；针对不同的用户，则可以创建新的帐号信息，下发新的登录态等；

对于 获取用户信息 ，后端可以用 access_token 向微信请求获得。

小程序老授权登录

在微信小程序中，由于微信客户端拥有控制力，第三方业务与微信之间不再需要跳转，只要调用微信提供的接口，微信客户端可以保证授权的有效性，因此授权登录相比网页开发较为简单，但这同时也意味着微信随时可以改变接口的行为。直到目前，小程序授权登录的行为发生过两次改动：

小程序刚推出时，微信提供了 wx.login 和 wx.getUserInfo 两个接口，分别用于登录和 授权获取用户信息 ；其中 wx.login 是静默的，会直接返回可换取 OpenID 的 code 和用于解密数据的 session_key； wx.getUserInfo 会弹出授权弹窗，经过授权后，会返回加密的用户数据，可以由后端凭 session_key 进行解密。加密的目的是为了防止用户篡改信息，从而限制违规头像昵称的产生，这一点不在本文的讨论范围内。

此后不久， wx.getUserInfo 被改为不再主动弹出授权，而是会在未授权情况下静默失败；授权则需要使用微信提供的专门 button 组件进行触发，这是为了遏止部分小程序一启动就弹出授权，或在本来不需要用户信息的情况下超标获取的问题。对于一些使用 WebView 的小程序，由于 WebView 页面中无法承载原生的 button 组件，这次改动就需要使用一个原生的授权页面来适配。

老的这一套授权登录流程虽然有它繁琐的地方，但长久以来，我们都忘记了其中最大的一个方便点：经过一次授权之后，小程序可以随时静默获取用户的信息。当用户更改了昵称或头像，只要打开已授权的小程序，小程序就能直接获取到修改后的信息，而无需用户再次授权。

新授权登录的产品形态

从官方文档中可以看出，小程序授权登录机制调整后，主要存在两个改动点：

在 wx.login 接口中，现在可以直接获取到用户的 UnionID，而无需通过授权获得，这其实是修复了之前的 Bug，同时鼓励各小程序业务尽可能不超标获取用户信息，遵循权限最小化原则；
新增了 wx.getUserProfile 接口，代替原来的 wx.getUserInfo ，新的接口会主动弹出授权，但只能一次性获取当前的昵称头像，而且仍然需要在用户点击后调用。

从产品角度而言，这两点分别带来了不同的变化：

第一点对于需要获取 UnionID 的业务来说，可以让静默登录的能力真正可用。可以让用户在不授权昵称头像的情况下，使用尽可能多的功能，在需要时才提示授权，对于产品本身登录过程的转化率有很大帮助，同时也帮助微信保护用户隐私，是一个双赢的举措；

而第二点变化则可以看作是微信对用户信息匿名化的一个尝试。在此之前，微信推出了自定义昵称头像的功能，可以在授权时设置自定义的昵称头像，区别于微信本身的昵称头像，实现一定的匿名使用；但由于老授权登录接口是一次授权，用户一旦设置了自定义的昵称头像就无法修改。因此，为了能将一次授权改为每次授权，微信通过新增一个接口，让开发者对这一行为进行主动适配。

根据微信的要求，4 月 13 日之后，新发布的版本在支持 wx.getUserProfile 的情况下，不能再使用 wx.getUserInfo ，否则将收到默认的昵称头像。从微信开发者工具中也可以提前看到这一改动：获取到的头像会变成一张默认头像，昵称变为「微信用户」。

而适配这个接口也意味着产品交互需要发生改变，因为在此之后，一次授权只能获得一次性的昵称和头像，当用户对微信昵称头像进行了修改，小程序业务不但不能静默获取到修改后的昵称头像，完全无从得知头像昵称发生了变化，都必须通过重新授权才能实现。

对于本来需要获取用户昵称头像的小程序业务，我们探讨了一种比较合理的适配方式： 模拟原来的一次授权 、并且 提供手动修改头像昵称的入口 。通过对登录逻辑的改造，可以实现尽可能模拟原有的授权交互，只在首次使用时进行授权，但经过这一次授权后，昵称头像不会再更新；因此需要提供手动修改头像昵称的入口，让用户对「头像昵称不会自动同步、可以手动更新或修改」的行为有预期。