如何设计做产品中的第三方授权，账号绑定及解绑流程
关于第三方账号授权、账号绑定、账号解绑，你了解多少？...
本文作者王悠悠悠，互联网产品狗，静若瘫痪动若癫痫，爱好阅读和游玩。
上个月的时候，我们推出过一篇文章→《关于注册/登录功能的那些事儿》。作者在文末讲到，若要构建产品矩阵进行多平台间的用户打通，加上帐号绑定与解绑，并不是一时半会儿就能想清楚的需求，若大家感兴趣，她会继续补充帐号绑定等产品应该关心和设计的事情。
文章推出后，反响很好，大家也对其中的一些问题提出了很多看法，所以今天的文章中，作者会将大家的疑惑进行解答，并继续补充关于第三方授权登录和账号绑定与解绑方面的知识。
在正文开始之前，请大家先回顾一下→《关于注册/登录功能的那些事儿——前端设计+服务端设计》
先说一下第一个是否完全打通的问题，这取决于同一个开发者的app是否需要或者能够让用户感知到这些app都是属于同一个开发者的，即很容易让用户感知到“哦，这些都是一家公司的”。那么完全打通用户信息及绑定关系，是可以的，用户也是会接受的。
并且完全打通对于开发来说可以说是个一劳永逸的事情，之后的app用户系统这一块可以说没有开发量，直接接入就ok了。
我们可以简单归纳一下现在主流的用户系统服务端设计：
1. app级用户系统根据手机号邮箱注册或第三方授权创建用户身份，用户的身份信息、账号绑定、个人资料都保存在app服务端，也只对单一app有效，普遍中小app采用的都是此种系统。
2. 平台级用户系统
根据手机号、邮箱注册创建用户身份，用户的身份信息、账号绑定、个人资料都保存在统一的公司用户系统服务端，选择极少信息提供公开接口，接入的app只有读取权限。例如QQ、微博、微信等第三方授权。
3. 公司级用户系统
根据手机号、邮箱注册创建用户身份，用户的身份信息、账号绑定、个人资料都保存在统一的公司用户系统服务端，对接入的app有效，app端有读取修改权限。
前两个不展开说了，关于公司级用户系统可以举两个典型的例子，感兴趣的朋友可以体验一下。第一个是网易，第二个是百度。
大家可以回顾一下这两个公司的常用app。就我而言，网易是云音乐、考拉海购、网易有钱等；百度是百度地图、百度糯米等。
网易公司的用户系统是用网易邮箱去承载，但是承担的功能仅是提供一个用户身份，即unionID，用户的资料、帐号、第三方登录等都是app自己去实现的。
百度公司的用户系统是百度账号去承载，承担的功能除了提供用户身份unionID外，用户资料、第三方登录都是保存在用户系统的，app端有修改权限用户系统资料。
两家的用户系统都没做账号绑定的事情，我认为原因可能是他们建立用户系统的时候还不存在繁琐的账号绑定，后期想加上的话就会牵扯到新老账号的数据合并问题，这是很头疼的问题。
而关于用户资料是存在app端还是用户系统，网易是存在app端，百度是存在用户系统，这两家公司区别的原因我分析有二：
一是百度系app本身是偏工具的，浏览器、地图、网盘等对于用户资料和个人中心没有太多的定制化需求，只需要基本的头像昵称即可，所以将用户资料这块保存在用户系统，app端基本直接接入即可；
网易类是比较重用户资料和个人中心的，简单的通用的并且是同步到所有app的设计是无法满足各app产品的，所以选择自建。包括百度需要有稍强一点的用户资料的app（例如百度音乐）都会在用户系统的基础上在app端去自建和完善用户资料。
第二个问题即不能将手机作为唯一标识的担心实际是：
一般来讲，有以下方法可以解决上述问题：
所以只要做好安全验证问题，用手机号作为唯一标识也没有问题，当然第二个问题事关运营商，查了下资料，作为互联网服务商上技术上是无解的，只能尽可能提醒用户绑定与解绑手机。
简单来说就是第三方有一个公开的授权接口，你有权访问并向用户确认后能够返回此用户在第三方的身份openid，可作为app生成自己用户身份的验证。主流程图
调取第三方sdk，查询此openid是否已有appuserid。
第三方授权能够给用户提供便捷的注册和登录方式，这是好的一点，但是正因为操作太便捷，没有参与感，所以用户很容易忘记自己的登录方式。
账号绑定的目的就是避免用户忘记登录方式，每次授权都在app内创建一个用户身份，不利于用户操作的同时，也不利于产品用户信息留存。所以从产品设计上来讲，用户的登录和注册方式尽量简单、多种，但是尽量在非必要非用户自主想创建另外账号的情况下，尽量一个用户在一个app只存在一个身份。
主流程图
绑定手机号绑定手机号
Step1：用户输入手机号点击获取验证码，客户端进行基本判断（后面详细介绍）后，app服务端发送验证码；
Step2：用户系统服务端验证用户的手机号是否已存在对应的appuserid。
App服务端查询账号信息，是否存在appuserid。
主流程图
账号解绑更绑手机号
Step1：原手机号+验证码，app服务端验证是否为真，为真发送验证码；
Step2：新手机号+验证码+密码，app服务端验证手机号+验证码是否为真，为真进行step3；
Step3：用户系统服务验证此手机号是否已存在unionid。
Step1：当前第三方授权是否已经绑定手机号，若是，成功解绑；若否进行step2；
Step2：当前第三方授权是否绑定其他第三方授权登陆，若是进行step3，若否提示无法解绑，首先请绑定手机号；
Step3：当前第三方授权是否为最早一个绑定（即注册账号）。
ps：这里被开发同事验证不能抹去登录信息，因为我们只有调取接口的权限。但是当时之所以想要这么设计，是为了账号安全。
可以试想一个场景，我把你的账号绑定到我的微信/微博等，然后接触你的账号，相当于这个账号就归我了－－事实证明现在的权限没办法解决这个问题。
本文作者王悠悠悠，互联网产品狗，静若瘫痪动若癫痫，爱好阅读和游玩。
上个月的时候，我们推出过一篇文章→《关于注册/登录功能的那些事儿》。作者在文末讲到，若要构建产品矩阵进行多平台间的用户打通，加上帐号绑定与解绑，并不是一时半会儿就能想清楚的需求，若大家感兴趣，她会继续补充帐号绑定等产品应该关心和设计的事情。
文章推出后，反响很好，大家也对其中的一些问题提出了很多看法，所以今天的文章中，作者会将大家的疑惑进行解答，并继续补充关于第三方授权登录和账号绑定与解绑方面的知识。
在正文开始之前，请大家先回顾一下→《关于注册/登录功能的那些事儿——前端设计+服务端设计》
以下是正文
之前总结了用户系统登录和注册及帐号打通的问题，有两个问题大家争议得比较多。第一，为什么不完全打通，为什么每一个app要保留自己的用户资料和绑定关系；
第二，不应该用手机号作为唯一的识别方式。
先说一下第一个是否完全打通的问题，这取决于同一个开发者的app是否需要或者能够让用户感知到这些app都是属于同一个开发者的，即很容易让用户感知到“哦，这些都是一家公司的”。那么完全打通用户信息及绑定关系，是可以的，用户也是会接受的。
并且完全打通对于开发来说可以说是个一劳永逸的事情，之后的app用户系统这一块可以说没有开发量，直接接入就ok了。
我们可以简单归纳一下现在主流的用户系统服务端设计：
1. app级用户系统根据手机号邮箱注册或第三方授权创建用户身份，用户的身份信息、账号绑定、个人资料都保存在app服务端，也只对单一app有效，普遍中小app采用的都是此种系统。
2. 平台级用户系统
根据手机号、邮箱注册创建用户身份，用户的身份信息、账号绑定、个人资料都保存在统一的公司用户系统服务端，选择极少信息提供公开接口，接入的app只有读取权限。例如QQ、微博、微信等第三方授权。
3. 公司级用户系统
根据手机号、邮箱注册创建用户身份，用户的身份信息、账号绑定、个人资料都保存在统一的公司用户系统服务端，对接入的app有效，app端有读取修改权限。
前两个不展开说了，关于公司级用户系统可以举两个典型的例子，感兴趣的朋友可以体验一下。第一个是网易，第二个是百度。
大家可以回顾一下这两个公司的常用app。就我而言，网易是云音乐、考拉海购、网易有钱等；百度是百度地图、百度糯米等。
网易公司的用户系统是用网易邮箱去承载，但是承担的功能仅是提供一个用户身份，即unionID，用户的资料、帐号、第三方登录等都是app自己去实现的。
百度公司的用户系统是百度账号去承载，承担的功能除了提供用户身份unionID外，用户资料、第三方登录都是保存在用户系统的，app端有修改权限用户系统资料。
两家的用户系统都没做账号绑定的事情，我认为原因可能是他们建立用户系统的时候还不存在繁琐的账号绑定，后期想加上的话就会牵扯到新老账号的数据合并问题，这是很头疼的问题。
而关于用户资料是存在app端还是用户系统，网易是存在app端，百度是存在用户系统，这两家公司区别的原因我分析有二：
一是百度系app本身是偏工具的，浏览器、地图、网盘等对于用户资料和个人中心没有太多的定制化需求，只需要基本的头像昵称即可，所以将用户资料这块保存在用户系统，app端基本直接接入即可；
网易类是比较重用户资料和个人中心的，简单的通用的并且是同步到所有app的设计是无法满足各app产品的，所以选择自建。包括百度需要有稍强一点的用户资料的app（例如百度音乐）都会在用户系统的基础上在app端去自建和完善用户资料。
第二个问题即不能将手机作为唯一标识的担心实际是：
- 用户手机号更换后无法找回密码；
- 旧手机号码被重新激活后账号信息泄露。这个问题实际上需要的是安全验证。
一般来讲，有以下方法可以解决上述问题：
- 账号绑定与解绑；
- 设置安全问题；
- app用户行为验证；
- 账号申诉。
所以只要做好安全验证问题，用手机号作为唯一标识也没有问题，当然第二个问题事关运营商，查了下资料，作为互联网服务商上技术上是无解的，只能尽可能提醒用户绑定与解绑手机。
－－－－解答疑惑的分割线－－－－
接下来，我会继续补充第三方授权登录和账号绑定与解绑方面的知识。第三方授权登录
上篇文章我们介绍过第三方授权的用户不是用户系统的用户，仅是单一app的用户，此原则在此篇仍适用。第三方授权是为app注册登录提供一种便捷的方式和补充，那么第三方授权的登录和注册是怎么回事呢？简单来说就是第三方有一个公开的授权接口，你有权访问并向用户确认后能够返回此用户在第三方的身份openid，可作为app生成自己用户身份的验证。主流程图
第三方授权注册登录
调取第三方sdk，查询此openid是否已有appuserid。
若是，登陆；
若否，创建appuserid并将基本资料存入app服务端。
账号绑定
账号绑定分为绑定手机号和绑定第三方授权账号。第三方授权能够给用户提供便捷的注册和登录方式，这是好的一点，但是正因为操作太便捷，没有参与感，所以用户很容易忘记自己的登录方式。
账号绑定的目的就是避免用户忘记登录方式，每次授权都在app内创建一个用户身份，不利于用户操作的同时，也不利于产品用户信息留存。所以从产品设计上来讲，用户的登录和注册方式尽量简单、多种，但是尽量在非必要非用户自主想创建另外账号的情况下，尽量一个用户在一个app只存在一个身份。
主流程图
绑定手机号
Step1：用户输入手机号点击获取验证码，客户端进行基本判断（后面详细介绍）后，app服务端发送验证码；
Step2：用户系统服务端验证用户的手机号是否已存在对应的appuserid。
绑定第三方授权若是，提示此号已绑定，先更换绑定手机号；
若否，用户系统按照手机号注册流程，用户系统创建unionid，将union传给app并关联当前登陆的appuserid，绑定成功。
App服务端查询账号信息，是否存在appuserid。
若是，提示此号已绑定，建议先解绑；
若否，将此第三方授权openid绑定到登陆的appuserid中；绑定成功。
账号解绑
账号解绑也分为手机号和第三方授权。手机号只允许更换绑定不允许解除绑定。更换绑定的场景就在于用户更换了手机号，为了账号安全将之前的信息迁移到新的手机号中，并将更换的原手机号从系统中删除，若再次注册将视为新账号。主流程图
账号解绑
Step1：原手机号+验证码，app服务端验证是否为真，为真发送验证码；
Step2：新手机号+验证码+密码，app服务端验证手机号+验证码是否为真，为真进行step3；
Step3：用户系统服务验证此手机号是否已存在unionid。
解绑第三方授权若是，提示更绑失败；
若否，将新手机号替换原手机号，关联原手机号unionid，appuserid；并将原手机号从用户系统中删除。
Step1：当前第三方授权是否已经绑定手机号，若是，成功解绑；若否进行step2；
Step2：当前第三方授权是否绑定其他第三方授权登陆，若是进行step3，若否提示无法解绑，首先请绑定手机号；
Step3：当前第三方授权是否为最早一个绑定（即注册账号）。
若是，调取第三方授权登陆页面，用户重新登陆要解绑账号+密码（需要确认是否能抹除用户登录信息要求输入账号密码），登陆成功则解绑成功。
ps：这里被开发同事验证不能抹去登录信息，因为我们只有调取接口的权限。但是当时之所以想要这么设计，是为了账号安全。
可以试想一个场景，我把你的账号绑定到我的微信/微博等，然后接触你的账号，相当于这个账号就归我了－－事实证明现在的权限没办法解决这个问题。
本文作者王悠悠悠，互联网产品狗，微信WY54EF，欢迎交流。若否，解绑成功。
