关于java:多账号统一登陆怎么实现

35次阅读

共计 3864 个字符,预计需要花费 10 分钟才能阅读完成。

起源: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. 用户通过 手机号 + 验证码 登录后,也可抉择设置明码,而后就能够通过 手机号 + 明码 的形式登录,即:明码是非必填项。

用户表设计:

iduser_nameuser_passworduser_mobilestatemore
用户 id用户名用户明码手机号码账号状态其余信息

1.2 引入第三方账户计划

1.2.1 微博登录

进入 Web2.0 时代 , 微博凋谢了第三方网站登录, 产品说, 这个咱们得要, 加个用微博帐号就能登录咱们的 App吧,而且得和咱们本人的用户表关联。

流程:

  1. 客户端调用微博登录的界面,进行输出用户名、明码,登录胜利后,会返回 access_token, 通过 access_token调取 API接口获取用户信息。
  2. 服务端通过用户信息在咱们用户表创立一个账号,当前,该第三方账号即可通过该微博账号间接进行登陆。

微博用户信息表设计:

iduser_iduidaccess_token
主键 id用户 id微博惟一 id受权码

1.2.2 噩梦降临

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

二、优化账号体系

2.1 原账号体系剖析

  1. 自建登陆体系:无论 手机号 + 明码 , 还是 手机号 + 验证码 , 都是一种 用户信息 + 明码 的验证模式;
  2. 第三方登录:也是 用户信息 + 明码 的模式, 用户信息即第三方零碎中的 ID(第三方零碎中的惟一标识), 明码即 access_token, 只不过是一种有应用时效定期批改的明码。

2.2 新的账号体系

2.2.1 数据表设计

用户根底信息表:

idnicknameavatarmore
用户 id昵称头像其余信息

用户受权信息表:

iduser_ididentity_typeidentifiercredential
主键 id用户 id登录类型(手机号 / 邮箱) 或第三方利用名称 (微信 / 微博等)手机号 / 邮箱 / 第三方的惟一标识明码凭证 (自建账号的保留明码, 第三方的保留 token)

阐明:

  1. 用户表分为 用户根底信息表 + 用户受权信息表
  2. 用户信息表不保留任何明码, 不保留任何登录信息 (如用户名, 手机号, 邮箱), 只留有昵称、头像等根底信息; 所有和受权相干, 都放在用户信息受权表, 用户信息表和用户受权表是一对多的关系

2.2.2 登录流程

  • 手机号 + 验证码

沿用之前的计划。

  • 邮箱 / 手机号 + 明码:

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

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

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

查问 type='weixin' 联合 identifier='微信 openId', 如果有记录, 则间接登录胜利, 并更新 token; 假如与微信服务器通信不被劫持的状况下无需判断凭证问题。

2.2.3 优缺点

长处:

  1. 登录类型有限扩大, 新增登录类型的开发成本显著升高;
  2. 原来条件下, 利用须要验证手机号是否已验证和邮箱是否已验证, 须要绝对应多一个字段如 phone_verifiedemail_verified, 现在只有在 用户受权信息表 表中减少一个对立的 verified 字段, 每种登录形式都能够直观看到是否已验证状况;
  3. 用户受权信息表 增加相应的工夫和 IP 地址, 就能够更加残缺地跟踪用户的应用习惯, 比方: 曾经不应用微博登录两年多, 曾经绑定微信 300 天;
  4. 如果你说邮箱和手机号就是用户信息的组成部分, users 表只管拓展, users 表里仍然有 email , phone , 但他们仅仅作为“展现用处”, 和昵称, 头像或者性别这些属性没有本质区别;
  5. 可按需绑定任意数量的同类型登录形式, 即一个用户能够绑定多个微信, 能够有多个邮箱, 能够有多个手机号。当然你也能够限度一种登录形式只有一条记录;

毛病 :

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

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

该微博曾经在本站存在, 以后用户未登录, 间接登录胜利;

该微博未在本站注册, 但以后用户曾经登录并关联的是另一个微博帐号, 作何解决取决于是否容许绑定多个微博帐号;

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

该微博曾经注册, 用户又已应用该帐号登录, 为何他反复绑定本人;

该微博曾经在本站存在, 但以后用户曾经登录并关联的是另一个微博帐号, 作何解决?

三、一键登陆

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 调用运营商一键登录的接口,调用胜利就返回手机号码了。服务器用手机号进行登录或注册操作,返回操作后果给客户端,实现一键登录。

四、小结

博主看来,没有最好的计划,抉择实用以后零碎的设计即可。不要深究孰优孰劣,鞋合不合脚,只有脚晓得。

近期热文举荐:

1.1,000+ 道 Java 面试题及答案整顿(2021 最新版)

2. 别在再满屏的 if/ else 了,试试策略模式,真香!!

3. 卧槽!Java 中的 xx ≠ null 是什么新语法?

4.Spring Boot 2.5 重磅公布,光明模式太炸了!

5.《Java 开发手册(嵩山版)》最新公布,速速下载!

感觉不错,别忘了顺手点赞 + 转发哦!

正文完
 0