多账号统一登陆，怎么实现？

最新推荐文章于 2024-12-18 21:46:23 发布

2401_83329718

最新推荐文章于 2024-12-18 21:46:23 发布

阅读量853

点赞数 13

分类专栏：程序员文章标签： java 面试数据库

本文链接：https://blog.csdn.net/2401_83329718/article/details/138014742

版权

程序员专栏收录该内容

724 篇文章

订阅专栏

文章探讨了服务端如何处理第三方登录问题，提出将用户信息和授权信息分离到两个表的设计，实现登录类型的扩展和验证优化。同时介绍了使用本机号码认证（一键登录）以简化登录流程，以及提供Java开发者的学习资源。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

服务端通过用户信息在我们用户表创建一个账号，以后，该第三方账号即可通过该微博账号直接进行登陆。

微博用户信息表设计：

| id | user_id | uid | access_token |

| :-- | :-- | :-- | :-- |

1.2.2 噩梦来临

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

二、优化账号体系

2.1 原账号体系分析

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

2.2 新的账号体系

2.2.1 数据表设计

用户基础信息表：

| :-- | :-- | :-- | :-- |

| 用户id | 昵称 | 头像 | 其他信息 |

用户授权信息表：

| :-- | :-- | :-- | :-- | :-- |

说明：

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

2.2.2 登录流程

手机号+验证码

沿用之前的方案。

邮箱/手机号+密码:

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

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

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

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

2.2.3 优缺点

优点:

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

缺点 :

用户同时存在邮箱、用户名、手机号等多种站内登录方式时, 改密码时必须一起改, 否则就变成了 邮箱+新密码, 手机号+旧密码都可以登录, 肯定是很诡异的情况;
代码量增加了, 有些情况下逻辑判断增加了, 难度增大了; 举个例子, 无论用户是否已登录, 无论用户是否已注册过, 都是点击同一链接前往微博第三方授权后返回, 可能出现几种情况：

该微博在本站未注册过, 很好, 直接给他注册关联并登录；

该微博已经在本站存在, 当前用户未登录, 直接登录成功；

该微博未在本站注册, 但当前用户已经登录并关联的是另一个微博帐号, 作何处理取决于是否允许绑定多个微博帐号；

该微博未在本站注册过, 当前用户已登录, 尝试进行绑定操作；

该微博已经注册, 用户又已使用该帐号登录, 为何他重复绑定自己;

该微博已经在本站存在, 但当前用户已经登录并关联的是另一个微博帐号, 作何处理?

三、一键登陆

3.1 背景

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

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

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

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

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

3.2 本机号码认证

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

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

主要步骤如下：

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

四、小结

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

近期热文推荐：

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

Java核心架构进阶知识点

面试成功其实都是必然发生的事情，因为在此之前我做足了充分的准备工作，不单单是纯粹的刷题，更多的还会去刷一些Java核心架构进阶知识点，比如：JVM、高并发、多线程、缓存、Spring相关、分布式、微服务、RPC、网络、设计模式、MQ、Redis、MySQL、设计模式、负载均衡、算法、数据结构、kafka、ZK、集群等。而这些也全被整理浓缩到了一份pdf——《Java核心架构进阶知识点整理》，全部都是精华中的精华，本着共赢的心态，好东西自然也是要分享的