从账号/登录/统一认证角度，拆解用户体系的核心与难点

时光时光慢些吧 2023-07-22 03:23:27

这篇文章有将近六千字，阅读它你大概会花费20分钟，给你的回报会是：

了解用户体系存在的意义
了解与用户体系有关的一些基本概念
了解用户体系打造的核心和难点
了解统一认证（通行证）的规则
避开用户体系打造的一些坑

开始，GOGO！

做产品，看到每一个功能我们都会首先想到这个功能是为了解决什么需求而诞生的，这个需求在现实生活中有什么具体的应用场景吗？这是每一个功能每乃至每一个产品存在的意义所在。

一、用户体系存在的意义

用户反映到产品上就是账号。用户使用每一个产品都会产生数据，比如在淘宝上购物会产生订单、在网易云音乐上听歌会产生歌单，这些数据每个人都是不同的，那么我们怎么才能让不同的人使用产品的时候拿到属于自己的数据呢？

这个时候我们就需要有一个标的用来标记这些不同的数据的所属，用户使用产品的时候也需要一个凭证来获取属于自己的数据，这个标的、这个凭证就是账号，当同一个用户拥有多个账号时就产生了用户体系！

现在我们就可以明白，用户体系存在的第一个意义就在于存储数据以及识别用户的身份。

接下来我们通过生活中的一个场景来看一下用户体系的第二个意义：

场景：

小林子注册了某个高校的在线学习账号，为了方便记忆该校使用学号作为账号，他先用小学学号A注册，然后接着读了中学用的学号B注册，又有一天小林子去了学校的图书馆，小林子在图书馆的在线查阅系统里注册了账号C，毕业后他在这个学校任职教师，这个时候小林子又有了一个职工账号D专门用来登录教学管理后台。

截止到现在小林子一共有四个账号，这四个账号都会经常使用，而且去登录不同的系统就要使用不用的账号不同的密码，小林子经常因为记错账号和密码的事儿试好几次才能登录成功，可是把小林子难为透了。

试想如果这个时候可以让小林子只记住一个账号一个密码就可以登录四个不同的地方那该是多好的事情。

为了解决这个问题我们的前辈又提出了统一认证的概念：

统一认证：即通过某一个唯一信息将同一个人的不同账号关联起来进行管理，他们公用同一个秘钥，通过这个唯一信息可以登录任何一个产品。这样就大大减轻了用户的记忆负担，减少了使用过程中的出错。

所以用户体系的存在的第二个意义就是：让登录更简单，让用户更方便。

另外，从战略层面上考虑，做好完善的用户体系更利于用户信息的收集与统计，更好的为大数据分析打好基础。

二、几个基本概念

说完了用户体系的意义，为了接下来方便、准确的描述，我们先规定几个用户体系基本的概念。

1. 通行证账号：用来唯一标识一个用户

用户（自然人为主的民事主体）：认知上成年人以实名为识别标准，B端产品会存在以法人为识别标准的情况。
用户对应通行证账号，每个用户一个通行证账号。

2. 业务账号：单个业务系统的注册账号

a. 业务账号为单个系统数据绑定的最小账号单位，每个用户每个业务系统可对应多个业务账号。
b. 游客账号：业务账号的一种，指未注册账号的用户进入系统后自动产生的账号，用于记录用户游客身份状态下的使用数据。

游客账号一般与设备号绑定
在游客状态下一般只能使用部分功能

3. 用户名：可用于登录的一个信息

通行证账号
业务账号
用户自行设置的某些绑定信息，如：昵称、手机号、第三方账号等

三、核心和难点（含认证规则）

有了前边的准备内容，接下来就是用于体系打造的灵魂部分了，单账号用户需要关注的是用户身份的验证方法（秘钥）以及账号安全问题，但是并不成体系，我们这里主要说明多账号的认证体系。

1. 核心

最初说到用户体系的意义之一就是通过多账号认证的方式来优化登录、方便用户，那么如何将多个账号进行认证生成通行证账号自然就是打造用户体系的第一个核心，也即：制定账号的认证规则。

账号认证完之后，在长期的使用过程中难免会存在信息更新的需要，比如要改一下名字，比如要换一个手机号等等，因为多账号的统一认证是以某些关键信息为识别从而将多账号进行绑定的，所以更新信息的时候也会发生账号绑定的情况，那么我们还需要处理好第二个核心，即：制定账号关键信息的更新规则。

账号的认证处理完了，接下来就是登录了，只有让用户完成了登录过程才算是做完了用户体系的闭环，这也就是打造用户体系的第三个核心，即：建立安全易用的登录机制以及完善可靠的身份找回机制。

核心一：认证规则

账号是用户数据的绑定单元，不同的用户自然数据不能相互混淆，因此用户认证最基础的规则就是同一用户的不同账号才可以进行认证。所以我们需要找到一个可以唯一识别用户身份的元素作为认证的标准，按照认证方式不同可分为以下两类：

（1）自动认证（被动认证）：即注册账号时若发现身份信息相同的账号即自动进行认证，自动产生通行证账号。

常见的可以代表用户身份的元素有手机号、邮箱、身份证号等。

（2）主动认证：注册账号时不自动进行认证，而是由用户自行选择将某几个账号进行认证进而产生通行证账号。

此种情况下一般需要后台自动为通行证账号产生一个身份识别信息，用以区分不同的用户。

核心二：更新规则

一个账号主要包含两部分信息：

一部分是身份识别信息，用来唯一识别一个用户，比如手机号、邮箱等，身份识别信息不同的账号认为是属于两个不同的用户。
一部分是身份公示信息，用来对外展示自己的身份属性，比如昵称、姓名、头像等。不过两者之间也可能会有重复的，这完全取决于产品的意图以及如何设计。

这两类信息的更新是不同的，身份公示信息不会影响到账号的认证，只会改变账号对外显示的公开信息，所以这里主要考虑的是身份识别信息的更新。

既然更新影响的也是多账号是否会认证的问题，那么更新时发生认证的规则自然跟注册时是一致的，在不发生认证的情况下直接更新原通行证账号信息即可。

核心三：登录及身份找回

首先明确一件事，用户使用产品时产生的数据是绑定在账号上的，那么不同的人想要拿到属于自己的数据就要证明某个账号是属于自己的，这个就是登录的本质。

注册的时候用户跟服务器为自己的账号约定了一个暗号（密码），跟服务器约定好每次我说对暗号的时候就说明我是这个账号的主人，服务器就把这个账号的数据交给我，这就完成了登录。

不巧有时候自己忘记了这个暗号是什么，需要向服务器找回暗号，那么服务器为了每个人的数据安全自然就需要先确认一下这个账号确实是属于你的才能够告诉你旧暗号或者重新与你约定一个新暗号，这就是密码找回。

如果连用户名都忘记了呢？

那么还是要用同样的办法，先告诉服务器一些账号的相关信息，让服务器通过这些相关信息帮你从数据库中找到符合你的条件的用户名，这就是用户名找回。用户名找回和密码找回加起来就是身份找回。

看完上边的一段话，我们就可以明白，登录和身份找回都是用户向服务器出示一些可以证明自己身份的信息来从服务器拿到相应的信息的过程。那么常见的证明自己身份的手段都有哪些呢？

用户（用户名的所有权）的验证方法：一般用于验证通过后登录或允许修改关键信息，支付系统也用于检测到风险时支付前的身份验证。

第一：用户所知道的某个秘密信息，如用户口令。

静态/动态口令：动态口令即每次登录时向用户的其他绑定账户（如：邮箱、手机号）中发送随机密码。
密保问题（弱）
手机号验证：手机号+验证码
实名认证：姓名+证件号，调用实名认证接口。例如国政通、支付宝、手机运营商
银行卡验证：姓名+给银行卡打笔钱
问题验证：需回答与系统使用相关的记录，以银行为例：名下的银行卡数量、卡号、办卡时间、余额、最近三次消费时间以及消费金额等等。

第二：用户所持有的某个秘密信息(硬件)，即用户必须持有合法的随身携带的物理介质，如磁卡、智能卡或用户所申请领取的公钥证书。

动态令牌
U盾

第三：用户所具有的某些生物特征，如指纹，声音，DNA图案，视网膜扫描等。

第四：任何一种方式都不是万全的，都需要配备人工辅助验证服务。

2. 难点

有些聪明的同学看完之后觉得，这不是很简单吗，规定一个身份识别信息，只要这个信息一致就进行账号认证并产生通行证账号就可以了嘛，但是事情真的这么简单吗？答案当然是否！

顺着账号认证考虑，假如一不小心填写错了身份识别信息就有可能会导致错误的将不同的两个人合并到一个通行证账号上。

举个栗子：

我们以手机号相同作为识别唯一用户的标准，手机号相同的账号会合并起来公用同一个通行证账号，现在已经存在了一个用户小林子，使用的手机号为A，这个时候新注册了一个用户大林子，结果大林子填写的手机号不小心也填成了A，这个时候就会导致小林子和大林子被合并在了一起，即他们的登录信息现在是不分彼此的了。

而且小林子以后进入产品后会看到大林子昨天买了一个红色小内内，大林子进入产品后会看到小林子这几天一直在跟自己的暗恋女神发一些不可描述的互动信息……，这显然是个很严重的问题。

再举一个栗子：

小林子注册通行证账号的时候写的姓名是帅气的小林子，这个账号是用来学习研究生课程用的，后来老师看到了这个名字说我们为了方便老师认识每个同学必须把名字改成真实姓名，于是小林子就把名字改成了丑丑的小林子。

本来觉得一切相安无事，但是直到有一天自己的同学看到了小林子在公共论坛发表的泡妞攻略帖子，还被管理员加了精，这可不得了了，这一下子让小林子辛辛苦苦维护起来的正派形象轰然倒塌，小林子这才想起来自己的名称已经变成真实的姓名了，大事不妙！

上边两个情景里的故事分别说明了用户认证时经常发生的两个问题也是两个难点：认证导致的账号安全问题和账号与业务数据的关系问题。

难点一：账号安全问题

经过上边的例子说明，安全问题比较容易理解了，即容易被有意或无意的利用认证机制非法获取他人账号信息，解决这类问题时就需要在会发生认证的触发点上做好身份校验。

这里难点在于认证的触发点控制的不得当很容易影响产品的使用体验。

另外常用的身份识别信息比如手机号经常会出现运营商重新放号、亲人之间相互使用导致的错误认证问题，很多B段产品还会涉及到由机构代注册账号导致的批量认证问题。

解决此类问题一般而言建议大家根据具体产品的实际情况以及测重点适当做好取舍，比如银行类产品重点在于安全，那么在更换设备、修改手机号等重要信息时会采用密码校验、银行卡校验、客服视频连线或网点现场修改等多重认证，舍弃了体验保障了安全。

对于B端产品经常遇到的批量代注册行为，建议改变认证触发点，在注册时不进行认证，改为注册账号后在用户使用前需进行认领，在认领时补充身份识别信息并触发认证。

难点二：账号与业务数据的关系的处理

用户体系本身就是一个独立的身份验证系统，自成一块，用户体系的作用单纯的就是为了在用户进入产品时验证一下身份以此来决定允许还是不允许进入产品，本身并没不会对产品产生影响。

但是很多情况下用户在验证完成后所使用的产品也会用到用户的账号信息，比如在线学习平台上学习时会要求填写姓名，在社交类产品上发表言论的时候会显示昵称。

而姓名、昵称本身也是账号信息的一部分，那么这就涉及到了账号信息和产品本身对这两项信息进行更新时的相互覆盖行为，为什么说这里是一个难点呢？

因为不同的产品有不同的应用场景不用的特殊需求，就会导致有些产品相互覆盖为最优，有些产品不相互覆盖为最优，而如何考虑产品是不是应该相互覆盖需要丰富的经验才可以考虑全面，并且当将两种不同需求的产品都纳入用户体系的统一认证中时很容易就会产生矛盾。

在这里还是建立大家要根据不同的产品体系做不同的决策，以下几点可供参考：

优选原则：一处更新全部更新。
认证信息为与业务系统为弱关系，更多的代表自然人属性时可考虑一处更新全部更新，但是需要告知用户。
认证信息为与业务系统为强关系，很可能存在同一用户在不同业务系统使用不同的信息时，可将业务账号的绑定信息，与业务系统其它功能的使用独立开，即：业务系统使用的认证信息有单独的管理页面进行修改，修改时并不更新业务账号绑定的认证信息，业务账号绑定的认证信息单独进行维护，这样仍可一处更新时全部更新，此种情况可在更新业务信息时提示是否同步更新业务账号的认证信息。