微信小程序如何做好“授权”设计？

编辑导读：授权登录降低了用户注册账号时的操作成本，减少了产品的获客门槛。在本文中，作者结合案例，盘点了微信小程序授权登录设计中需要注意的几点问题，并对功能设计背后的设计思路与原理进行了简要的分析，供大家一同参考学习。

经历了四个小程序从0-1的设计/研发/上线的生命周期，深感小程序由于微信生态圈的影响，使它拥有很多便捷的封装功能，支持直接调用；同时弊端就是导致很多功能受限，不像原生app那样灵活多变。踩过无数坑，填过无数坑，所以萌生了总结小程序从头到尾各个环节的知识点，算存档也算分享给读者。适合刚入门接触小程序设计的同学或者是希望深入了解小程序的同学。

本文会从小程序一开始需要掌握的openID、UnionID、授权微信绑定手机号、获取其他用户信息，到亲身经历的单一登录流程改造跨平台适配作为案例，来介绍这些基本的参数和功能点如何设计。

01 openID

这是微信生态圈中，为了识别用户，每个小程序或者公众号对每个用户生成的一个唯一的ID，类似身份证号，针对该小程序或公众号具有唯一校验的属性。

储存openID，在用户下次进入小程序中，可识别用户身份，实现免登陆功能。小程序本身已经实现了登录功能，所以降低的开发成本。但获取openID只适用于规划中不含有app等其他平台应用的产品，如果想要实现多应用，在最初设计时，千万不要用openID！此处踩了大坑，后文中会详细介绍。

02 UnionID

如果开发者拥有多个移动应用、网站应用、和公众帐号（包括小程序），可通过 UnionID 来区分用户的唯一性，因为只要是同一个微信开放平台帐号下的移动应用、网站应用和公众帐号（包括小程序），用户的 UnionID 是唯一的。

换句话说，同一用户，对同一个微信开放平台下的不同应用，UnionID是相同的。注意：需要在微信开放平台将多个应用绑定在同一主体下，才能实现多应用共用一个UnionID，此配置需要前置进行。

03 其他用户信息

包括：用户信息、地理位置、定位、通讯地址、发票抬头、获取发票、运动步数。

04 微信绑定手机号

获取用户微信默认绑定的手机号，需要用户点击页面中的按钮（button)，才可以调用此功能。弹窗里支持用户修改手机号。如果业务中需要使用手机号来注册，就可以使用此功能获取，如业务中不强制要求，则只需获取用户openID/UnionID，在必要环节获取手机号，以提升用户体验。

介绍完openID/UnionID两者的区别，总结一下如何获取这两种ID：

• 点击页面中的按钮，弹出授权弹窗用户同意授权，才可获取。注意：用户的openID是放在【用户授权获取昵称和头像】中。引申一个知识点，还有一种方式是通过微信官方提供的登录功能获取openID，但在获取UnionID时会出现获取不到的情况，所以并不推荐使用此方法。
• 如果开发者帐号下存在同主体的公众号，并且该用户已经关注了该公众号。系统可以直接获取到用户的openID/UnionID，无需用户再次授权。
• 如果开发者帐号下存在同主体的公众号或移动应用，并且该用户已经授权登录过该公众号或移动应用。小程序用户无需再次授权。
• 用户在小程序（暂不支持小游戏）中支付完成后，5分钟内可获取用户的openID/UnionID，无需用户授权。此应用场景，作者所参与的项目中暂时没有使用过，但感觉扫码购类似的产品中应该会使用。

举个栗子，如果你想要获取用户的昵称头像和手机号，那么需要设计两次点击按钮，并且弹出两次授权弹窗，一次按钮点击获取一种授权，并且只能放在不同的按钮中。设计参考：美团、瑞幸、贝壳租房等小程序。

05 单一登录流程改造跨平台适配案例

5.1 旧方案的背景及流程图

我们的产品是一个分销平台，在最初规划和设计时，由于用人成本的因素，并没有预备研发app，只是单纯的希望通过小程序实现运营推广。但是在运营过程中，特殊的业务模式容易违规，怕被用户举报较多导致封号。高层决定不再依托于微信生态圈，从而倾斜资源自主研发app。所以当时小程序的整个登录流程，需要进行升级改造，用于适配app多设备注册登录。

旧方案流程如下：

踩的坑有两个地方：

第一，未与研发人员明确登录的概念，研发人员认为获取到用户的openID视为登录成功，对于我们的业务设计来说，获取到用户的手机号码才是真正意义的有效用户。

第二，由于开始并未规划app，导致研发人员在取用户信息时，选择了获取用户的openID，当多个移动应用时，无法获取用户的unionID，用户在各个应用中数据无法打通。

但是改造时，已有300多个授权手机号用户，所以改造方案花了很长时间探讨和研究，最终得出了一个相对来说完整的解决方案。

5.2 改造后的方案

在APP中，我们设计了微信授权登录、手机号验证码登录，手机号密码登录三种登录模式。微信授权登录的设计相对来说比较复杂。我只梳理了一个简易流程，研发的思路由项目经理负责输出。

产品设计思路：

研发思路（大力感谢小黑同学的贡献）：

在设计过程中，我遇到了一个思维误区，当时考虑的问题如下：

• 用户A—登录小程序—获取到openID—绑定了手机号1—视为老用户
• 老用户A—使用微信授权登录APP—获取到unionID—绑定了手机号2

如果用户在app登录，有了unionID，他绑定了其他手机号怎么办？这个时候创建一个新用户吗？那就存在一个unionid绑定了两个手机号的情况。

这种场景如何处理？

这个地方的盲区在于，我一定要把openID和unionID关联起来，其实大可不必。在这种情况下，以手机号为唯一标识，视为两个用户即可，只有绑定了相同手机号，数据才会互通合并。创建的新用户，他的openID为空，获取到unionID即可。

即： 用户A 是openID+手机号1，用户B是unionID+手机号2+openID为空。

06 写在后面

赞赏