平台第三方多账号统一登录的实现方案

如今，大多数的App都支持使用多个第三方账号进行登录，例如微信、QQ、微博等，将这种功能称为多账号统一登陆。在实现这一功能时，账号表设计和流程设计变得至关重要，否则可能导致后续扩展性极差。

本文旨在提供一些思路，梳理了博主根据所在公司账号模块的设计，并供读者参考。请注意，本文不包含任何代码实操。

一、 自建的登陆体系

1.1.1 手机号登陆注册

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

流程：

1、首先，输入手机号码，然后将其发送到服务器。首先判断该手机号码是否存在账号，如果不存在，则会生成一个随机验证码，并将手机号码和验证码绑定到Redis中，并设置一个特定的过期时间（通常为5分钟，这是常见的手机验证码有效期）。最后，将验证码通过短信发送给用户。

2、用户收到验证码后，在界面上填写验证码和密码等基本信息，然后将这些数据发送到服务器。服务器收到后，首先检查Redis中与该手机号码对应的验证码是否匹配，如果不匹配，则返回错误代码；如果匹配成功，则为用户创建一个账号并保存密码。

3、注册成功后，用户可以使用其手机号码和密码进行登录。

问题：

1、注册流程繁琐，用户需多次操作才能完成注册并开始使用服务。需要输入手机号、获取验证码，填写验证码、密码、用户名等多项信息，给用户带来不便。

2、密码遗忘问题常发生，一旦忘记密码，用户只能通过忘记密码功能来重设密码，增加了用户的麻烦和时间成本。

1.1.2 优化注册登陆

该方案的思路是减弱密码的必填性，允许用户通过手机号和验证码直接登录（同时保留手机号和密码登录方式）。

流程：

1、用户输入手机号，并将其发送到服务器。服务器生成随机验证码，并将手机号和验证码绑定到Redis中，并设置一个特定的过期时间（通常为5分钟，这是常见的手机验证码的有效期）。最后，服务器通过短信将验证码发送给用户。

2、用户收到验证码后，在界面上只需填写收到的验证码，并提交给服务器。服务器收到后，首先会检查Redis中与该手机号码对应的验证码是否一致。如果不一致，系统会返回错误码；如果一致，用户将直接登录。如果是老用户，系统将直接获取用户信息；如果是新用户，则会提示用户可以选择完善用户信息（但不强制要求）。

3、用户通过手机号和验证码登录后，也可以选择设置密码，然后就可以通过手机号和密码的方式登录。即密码是非必填项。

用户表设计：

1.2 引入第三方账户方案

1.2.1 微博登录

在迎接Web2.0时代的浪潮中，微博迈出了开放第三方网站登录的重要一步。产品团队决策称这是一个不可或缺的举措，因此决定添加微博账号登录功能至我们的App，同时还要确保与我们自己的用户表进行有效关联。

具体实现流程如下：

1、用户在客户端启动微博登录界面，输入其微博用户名和密码。成功登录后，系统将返回一个特殊的access_token。我们将利用这个access_token调用微博的API接口，获取用户的详细信息。

2、服务端接收到微博返回的用户信息后，将根据这些信息在我们的用户表中创建一个对应的账号。此后，用户便可通过该微博账号直接登录我们的App，实现了第三方账号与微博账号的便捷关联。

这一策略的实施，不仅加强了用户的登录体验，还拓宽了用户登录渠道。通过微博账号登录，我们能够更好地与用户进行互动，提供更个性化的服务。因此，这一重要举措将有助于我们在Web2.0时代保持竞争优势。

微博用户信息表设计：

1.2.2 噩梦来临

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

二、 优化账号体系

2.1 原账号体系分析

1、借助自建登录体系，我们实现了两种验证方式，即手机号加密码以及手机号加验证码。无论用户选择哪种方式进行验证，实际上都是采用用户信息与密码相结合的形式来进行身份验证。

2、对于第三方登录，其验证方式也是类似的，仍然采用用户信息与密码的形式。在这里，用户信息即为第三方系统中的唯一标识，而密码则表现为access_token。需要特别指出的是，access_token是一种定期修改的密码，具有时效性，这样做是为了保障安全性。

2.2 新的账号体系

2.2.1 数据表设计

用户基础信息表：

用户授权信息表：

说明：

1、用户表分为 用户基础信息表 + 用户授权信息表；

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

2.2.2 登录流程

• 手机号+验证码

沿用之前的方案。

• 邮箱/手机号+密码:

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

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

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

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

2.2.3 优缺点

优点：

• 登录类型无限扩展，新增登录类型的开发成本显著降低。
• 简化用户验证情况，通过在用户授权信息表中增加统一的verified字段，可以直观查看所有登录方式的验证状态，无需为每种登录方式增加额外字段。
• 可以更加完整地跟踪用户使用习惯，通过在用户授权信息表添加时间和IP地址，可以了解用户登录方式的历史情况，比如最近是否使用了某种登录方式，或者已经绑定某个登录方式多久。
• 允许按需绑定多个相同类型的登录方式，一个用户可以绑定多个微信账号、多个邮箱或多个手机号。

缺点：

• 当用户同时存在多种站内登录方式（如邮箱、用户名、手机号）时，改密码时需要同时修改所有方式的密码，否则可能导致奇怪的登录情况出现，比如使用新密码的邮箱登录或使用旧密码的手机号登录。
• 代码量增加，逻辑判断增多，难度增加。例如，处理第三方授权返回的情况时需要考虑多种可能性，涉及用户注册、登录、关联等不同情况。
• 在第三方登录场景中，可能出现微博已在本站注册但用户重复绑定自己的情况，或者当前用户已经关联其他微博帐号的情况，这些情况需要特殊处理，增加了代码复杂性和开发难度。

尽管存在一些缺点，但整体来看，优点的部分为系统提供了更多的灵活性和可扩展性，使得用户登录方式更加便利多样，同时用户信息的统一管理也有利于更全面地了解用户行为和习惯。

三、 一键登陆

3.1 背景

让我们来回顾一下“手机号+验证码”登录方式，同时优化这个过程：

• 传统方式中，用户需要输入手机号，等待验证码短信，再输入验证码，最后点击登录。整个流程耗时较长，操作相对繁琐。
• 它依赖于短信网络，如果短信无法收到，用户将无法登录。
• 安全方面存在验证码泄漏的风险。如果有人知道了你的手机号并获取了验证码，他可能会登录你的账号。

但让我们反思一下，为什么我们需要验证码？验证码的主要目的是确认这个手机号确实属于用户本人。那除了使用短信验证码，是否还有其他方式可以对手机号进行认证？

实际上，我们可以通过获取当前使用的手机号来进行验证。不过由于安全考虑，客户端是无法直接获取手机号的，但运营商却可以通过SIM卡数据查询到。

现在，运营商已经开放了相关的能力，这样我们可以在用户输入手机号后，通过调用运营商的接口来判断用户输入的手机号是否和本地号码一致。通过这种方式，用户就无需等待验证码短信和输入验证码，也不会受到短信网络的限制，大大简化了登录流程。

进一步思考，如果运营商能够直接将当前的号码返回给我们，而不仅仅用于验证，那么用户甚至连手机号都不需要手动填写了。

这就是本部分的主角：一键登录。通过一键登录，我们可以借助运营商的能力直接获取用户的手机号，从而简化登录过程，提高用户体验。这种新的方式为用户带来了便利，也为我们的产品增添了创新亮点。

3.2 本机号码认证

一键登录是一种极为便捷的登录方式，其优势明显。通过直接获取当前手机使用的手机卡号，用户可以快速完成注册和登录流程，将原本耗时20秒的操作缩短至仅需约2秒，极大地提升了用户登录体验。

以下是一键登录的主要步骤：

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

这种一键登录方式的简洁高效为用户提供了更便捷的登录体验，有效提高了用户的满意度。用户只需点击几下，便可完成登录，无需繁琐的手机号和验证码输入，同时也降低了验证码泄露的风险。这种创新的登录方式在现代移动应用中发挥着越来越重要的作用。

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

四、小结

在设计和选择系统方案时，没有绝对的最佳方案，而是应根据具体情况来选择适用的设计。每个系统和项目都有自己的特点和需求，因此需要灵活地根据实际情况做出决策。多账号统一登录实现方案同样也不断发展改进，相信以后还会有更好的方案来替代！

喜欢 (1)赏

【请潘老师喝杯Coffee吧！】

分享 (0)