多账号统一登陆，账号模块的系统设计

落日映苍穹つ 2022-09-09 11:56 242阅读 0赞

![0D5F937FE12312312D81F17F.jpg][]

程序员的成长之路

互联网/程序员/技术/资料共享

[关注][Link 1]

阅读本文大概需要 7 分钟。

来自：www.dustyblog.cn

现在几乎大部分的 `App` 都支持使用多个第三方账号进行登录，如：微信、QQ、微博等，我们把此称为多账号统一登陆。而这些账号的表设计，流程设计至关重要，不然后续扩展性贼差。

本文不提供任何代码实操，但是梳理一下博主根据我司账号模块的设计，提供思路，仅供参考。

## 一、 自建的登陆体系 ##

#### 1.1.1 手机号登陆注册 ####

> 该设计的思路是每个手机号对应一个用户，手机号为必填项。

流程：

1.  首先输入手机号，然后发送到服务端。先判断该手机号是否存在账号，如果没有，就会生成随机验证码，将手机号和验证码绑定到 `Redis`中，并设置一定的过期时间（过期时间一般是5分钟，这就是我们一般手机验证码的有效期），最后将验证码通过短信发送给用户。
2.  用户接收到验证码后，在界面填写验证码以及密码等基础信息，然后将这些数据发送服务端。服务端收到后，先判断在 `Redis`里面这个手机号对应的验证码是否一致，，失败就返回错误码，成功就给用户创建一个账号和保存密码。
3.  注册成功后，用户即可通过自己的 `手机号+密码`进行登陆。

问题：

1.  用户体验差，需要完成获取验证码，填写验证码/密码/用户名等诸多的信息完成注册，然后才能使用；
2.  容易遗忘密码，遗忘后，只能通过忘记密码来重新设置密码。

#### 1.1.2 优化注册登陆 ####

> 该方案的思路是弱化密码的必填性，即无论用户是否注册过，可通过 `手机号+验证码` 直接进行登陆(保留 `手机号+密码`登录的方式)。

流程：

1.  输入手机号，然后发送到服务端。服务端生成随机验证码，将手机号和验证码绑定到 `Redis`中，并设置一定的过期时间（过期时间一般是5分钟，这就是我们一般手机验证码的有效期），最后将验证码通过短信发送给用户。
2.  用户接收到验证码后，在界面只需填写收到的验证码，提交到服务端。服务端收到后，先判断在 `Redis`里面这个手机号对应的验证码是否一致，失败就返回错误码，成功就直接登录。如果是老用户，直接拉取用户信息；如果是新用户，则提示他可以完善用户信息（不强制）。
3.  用户通过 `手机号+验证码`登录后，也可选择设置密码，然后就可以通过 `手机号+密码`的方式登录，即：密码是非必填项。

用户表设计：

user\_name

user\_password

user\_mobile

state

### 1.2 引入第三方账户方案 ###

#### 1.2.1 微博登录 ####

进入 `Web2.0` 时代 ,微博开放了第三方网站登录, 产品说, 这个我们得要, 加个用微博帐号就能登录我们的 `App`吧，而且得和我们自己的用户表关联。

流程：

1.  客户端调用微博登录的界面，进行输入用户名、密码，登录成功后，会返回`access_token`,通过 `access_token`调取 `API`接口获取用户信息。
2.  服务端通过用户信息在我们用户表创建一个账号，以后，该第三方账号即可通过该微博账号直接进行登陆。

微博用户信息表设计：

user\_id

uid

access\_token

<table> 
 <thead> 
  <tr> 
   <td><br></td> 
   <td><br></td> 
   <td><br></td> 
   <td><br></td> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><p>主键id</p></td> 
   <td><p>用户id</p></td> 
   <td><p>微博唯一id</p></td> 
   <td><p>授权码</p></td> 
  </tr> 
 </tbody> 
</table>

#### 1.2.2 噩梦来临 ####

紧接着, QQ又开放用户登录了, 微信开放用户登录了，网易开发用户登录了。。。。。。一下子要接入好多家第三方登录了, 只能按照 “微博用户信息表” 新建一个表，重写一套各个第三方登录。

## 二、 优化账号体系 ##

### 2.1 原账号体系分析 ###

1.  自建登陆体系：无论 `手机号+密码` , 还是 `手机号+验证码` , 都是一种 `用户信息+密码` 的验证形式；
2.  第三方登录：也是 `用户信息+密码` 的形式, 用户信息即第三方系统中的 `ID`(第三方系统中的唯一标识), 密码即 `access_token`, 只不过是一种有使用时效定期修改的密码。

### 2.2 新的账号体系 ###

#### 2.2.1 数据表设计 ####

用户基础信息表：

nickname

avatar

用户授权信息表：

user\_id

identity\_type

identifier

credential

<table> 
 <thead> 
  <tr> 
   <td><br></td> 
   <td><br></td> 
   <td><br></td> 
   <td><br></td> 
   <td><br></td> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><p>主键id</p></td> 
   <td><p>用户id</p></td> 
   <td><p>登录类型(手机号/邮箱) 或第三方应用名称 (微信/微博等)</p></td> 
   <td><p>手机号/邮箱/第三方的唯一标识</p></td> 
   <td><p>密码凭证 (自建账号的保存密码, 第三方的保存 token)</p></td> 
  </tr> 
 </tbody> 
</table>

说明：

1.  用户表分为 `用户基础信息表` + `用户授权信息表`；
2.  用户信息表不保存任何密码, 不保存任何登录信息(如用户名, 手机号, 邮箱), 只留有昵称、头像等基础信息; 所有和授权相关,都放在用户信息授权表, **用户信息表和用户授权表是一对多的关系** 。

#### 2.2.2 登录流程 ####

*  `手机号+验证码`

沿用之前的方案。

*  `邮箱/手机号+密码`:

用户填写 `邮箱/手机号+密码`; 请求登录的时候, 先判断类型, 如手机号登录为例：

使用 `type='phone'` 结合 `identifier='手机号'` 查找, 如有, 取出并判断 `password_hash`(密码)是否和该条目的 `credential` 相符, 相符则通过验证, 随后通过 `user_id` 获取用户信息;

*  第三方登录, 如微信登录：

查询 `type='weixin'` 结合 `identifier='微信 openId'`, 如果有记录, 则直接登录成功, 并更新 `token`; 假设与微信服务器通信不被劫持的情况下无需判断凭证问题。

#### 2.2.3 优缺点 ####

优点:

1.  登录类型无限扩展, 新增登录类型的开发成本显著降低;
2.  原来条件下, 应用需要验证手机号是否已验证和邮箱是否已验证, 需要相对应多一个字段如`phone_verified` 和 `email_verified`, 如今只要在 `用户授权信息表` 表中增加一个统一的 `verified`字段, 每种登录方式都可以直观看到是否已验证情况;
3.  在 `用户授权信息表` 添加相应的时间和 `IP` 地址, 就可以更加完整地跟踪用户的使用习惯, 比如:已经不使用微博登录两年多, 已经绑定微信 300天;
4.  如果你说邮箱和手机号就是用户信息的组成部分, users 表尽管拓展, users 表里依然有email , phone , 但他们仅仅作为“展示用途”,和昵称,头像或者性别这些属性没有本质区别;
5.  可按需绑定任意数量的同类型登录方式, 即一个用户可以绑定多个微信, 可以有多个邮箱, 可以有多个手机号。当然你也可以限制一种登录方式只有一条记录;

缺点 :

1.  用户同时存在邮箱、用户名、手机号等多种站内登录方式时, 改密码时必须一起改, 否则就变成了 `邮箱+新密码`, `手机号+旧密码`都可以登录, 肯定是很诡异的情况;
2.  代码量增加了, 有些情况下逻辑判断增加了, 难度增大了; 举个例子, 无论用户是否已登录, 无论用户是否已注册过, 都是点击同一链接前往微博第三方授权后返回, 可能出现几种情况:
3.  
4.  
5.  1.  该微博在本站未注册过, 很好, 直接给他注册关联并登录；
6.  该微博已经在本站存在, 当前用户未登录, 直接登录成功；
7.  该微博未在本站注册, 但当前用户已经登录并关联的是另一个微博帐号, 作何处理取决于是否允许绑定多个微博帐号；
8.  该微博未在本站注册过, 当前用户已登录, 尝试进行绑定操作；
9.  该微博已经注册, 用户又已使用该帐号登录, 为何他重复绑定自己;
10. 该微博已经在本站存在, 但当前用户已经登录并关联的是另一个微博帐号, 作何处理?

## 三、 一键登陆 ##

### 3.1 背景 ###

回顾一下 `手机号+验证码` 的登录方式：

1.  输入手机号、等待验证码短信、输入验证码、点击登录。整个流程走完可能需要 20 秒以上，操作也比较繁琐；
2.  它是依赖短信网络的，因为如果收不到短信，也就登录不了了。
3.  从安全角度考虑，还存在验证码泄漏的风险。如果有人知道了你的手机号，并且窃取到了验证码，那他也能登录你的账号了。

但回过头来想一下，为什么我们需要验证码？验证码的作用就是确定这个手机号是你的，那除了使用短信，是否还有别的方式对手机号进行认证？

1.  如果能获取到当前使用的手机号，就能对用户输入的号码进行验证了。但出于安全考虑，客户端是无法直接获取到手机号的，运营商则可以通过 `SIM` 卡数据查询到。
2.  现在运营商已经开放了相关的能力，现在我们可以在用户输入手机号后，通过调用运营商的接口，判断用户输入的手机号是否和本地号码一致。这样一来，用户就省去了等待验证码短信、输入验证码的过程，也不受短信网络的限制，简化了登录流程。
3.  但再进一步想，如果运营商可以把当前的号码直接返回给我们，而不只是用于验证，那用户连手机号都不需要填了。

这就是该部分的主角：**一键登录** 。

### 3.2 本机号码认证 ###

获取到当前手机使用的手机卡号，直接使用这个号码进行登录，这就是一键登录。

这种登录方式的好处是显而易见的。它可以更方便、快捷地完成注册、登录流程，将原本可能需要 20 秒的流程，缩短到了 2 秒左右，很大程度上提升了登录的用户体验。

主要步骤如下：

1.  SDK 初始化：调用 SDK 的初始化方法，传入项目在平台上的 AppKey 和 AppSecret。
2.  唤起授权页：调用 SDK 唤起授权接口。SDK 会先向运营商发起获取手机号验码的请求，请求成功后跳转到授权页。授权页会显示手机号掩码以及运营商协议给用户确认。
3.  同意授权并登录：用户同意相关协议，点击授权页面的登录按钮，SDK 会请求本次取号的 token，请求成功后将 token 返回给客户端。
4.  取号：将获取到的 token 发送到我们自己的服务器，由服务器携带 token 调用运营商一键登录的接口，调用成功就返回手机号码了。服务器用手机号进行登录或注册操作，返回操作结果给客户端，完成一键登录。

目前阿里云已经提供了该方式并可兼容三大运营商的号码，详见 阿里云SDK:

https://help.aliyun.com/document\_detail/121113.html

## 四、小结 ##

博主看来，没有最好的方案，选择适用当前系统的设计即可。不要深究孰优孰劣，鞋合不合脚，只有脚知道。

<END>

**推荐阅读：**

[学会 IDEA REST Client后，postman就可以丢掉了...][IDEA REST Client_postman_...]

[MySQL 时间类型 datetime、bigint、timestamp，选哪个？][MySQL _ datetime_bigint_timestamp]

最近面试BAT，整理一份面试资料《Java面试BATJ通关手册》，覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。

**获取方式：点个「****在看****」，点击上方小卡片，进入公众号后回复「****面试题****」领取，更多内容陆续奉上。**

朕已阅 ![9d744a44b93a927055d8540448e48137.gif][]

[0D5F937FE12312312D81F17F.jpg]: /images/20220829/88df1504c60342ad87df70c3afd42272.png
[Link 1]: https://mp.weixin.qq.com/s?__biz=MzUyNDkzNzczNQ%3D%3D&chksm=fa24f0bacd5379ac93d74ffebac826d2401fd494f82e900e5102a8bf968f108e4ec72a4ad548&idx=3&lang=zh_CN&mid=2247487442&scene=21&sn=61e758d4bf9f15a3419fd028146469a3&token=1854383306#wechat_redirect
[IDEA REST Client_postman_...]: http://mp.weixin.qq.com/s?__biz=MzUyNDkzNzczNQ%3D%3D&chksm=fa275495cd50dd8351bdf006fcf00acc8cc8ebd718cd30cae8bdbc5e34a2e51dac37aba9426c&idx=1&mid=2247511037&scene=21&sn=4a03e1df9f0444551e5d53a0574ea1dd#wechat_redirect
[MySQL _ datetime_bigint_timestamp]: http://mp.weixin.qq.com/s?__biz=MzUyNDkzNzczNQ%3D%3D&chksm=fa275495cd50dd83dba5784b96cc3b24b6f30e9169f29e1eb488a6c45a7b5eaa0bd4ef9be457&idx=2&mid=2247511037&scene=21&sn=56bf2995508913b48ead2ff14d991647#wechat_redirect
[9d744a44b93a927055d8540448e48137.gif]: /images/20220829/fdbd45783e984f47adb2c7c177088b5e.png