【分布式项目】认证服务中心、社交登录OAuth2.0、单点登录、分布式Session解决方案

一. 注册

1.1 整合阿里云短信验证码

验证码重发前端倒计时。

验证码防刷后端校验:用户请求验证码时,将请求的IP和手机号码存入Redis,并对发送频率做限制,例如每分钟/单个IP/单个手机号仅能请求一次。如果脚本无法获取用户的真实IP,直接过滤这类请求。 再加上图像验证码,输入验证码后才能发送短信

1.2 注册数据校验

校验错误返回给前端注册页。并重定向回注册页面。(利用的Session原理,将数据放到Session中,只要跳到下一个页面取出数据后,session中数据就会删掉)【由于这里用到了Session, 所以必须解决分布式Session问题】

用过验证码必须把验证码删除(令牌机制)。

没有错误后调用用户中心远程服务进行注册,(用户名和手机号不能被占用)。

1.3 用户中心用户注册

使用异常机制,用户名和手机号不能被占用,如果查询到占用,抛出对应异常。
密码不能明文保存,MD5 & MD5盐值加密(Spring 家的密码加密器)

二、登录

2.1 简单的账号密码登录

数据库通过用户名查询到对应密码, 然后对比密码。
面试问题:如果用户很多,登录查数据库很慢怎么办? —> 数据库索引方面

2.2 社交登录 OAuth2.0

为了简化自我网站的登录和注册逻辑,引入社交登录
OAuth2.0流程:
【分布式项目】认证服务中心、社交登录OAuth2.0、单点登录、分布式Session解决方案_第1张图片

具体实现流程,以微博登录为例:
先申请微博网站接入接口,得到App Key(即client_id )

  1. 前端页面将用户引导进入微博登录网页, 请求地址包含client_id 以及登录成功的回调地址。
  2. 如果用户同意授权(用户输入微博的账号密码,登录并授权) 页面跳转至之前指定的回调地址,并在url上附带一个code
  3. 通过code码、client_id 、client_secret,换取Access Token(访问令牌),后台实现,code只能用一次
  4. 通过访问令牌,即可访问给定接口。

【分布式项目】认证服务中心、社交登录OAuth2.0、单点登录、分布式Session解决方案_第2张图片

三、分布式Session不同步,不共享问题

Session原理及问题

Session存在于服务器的内存中,服务器创建好Session后,命令浏览器保存sessionId到cookie中,浏览器每次访问都会带上cookie。

1.session不能跨不同域名共享,不同服务不能共享。 (不同域名附带不同的cookie)
2.同一服务,集群环境,session不能共享。

方案一,Session复制

Session复制, 同一服务在不同主机上,同步复制Session。
优点:Tomcat原生支持,只需要修改配置文件。
缺点:session同步需要数据传输,占用大量带宽,每个服务都存大量session,大型分布式集群情况下,不可能用。

方案二, 客户端存储

客户端存储。 优点是服务器不需要存储session,缺点是:都是缺点,危险,占带宽,存信息有限,可能被篡改
不会去用这种方式。

方案三, hash一致性

让同一个 ip 负载均衡到同一个服务器中, 优点,只需要改nginx,不需要修改应用代码,支持水平扩展。
缺点是:服务器闪断需重新登录,rehash可能会导致一部分用户路由不到正确的session

方案四,统一存储

优点:没有安全隐患、可以水平扩展。服务器重启闪断都不会导致session丢失
缺点:增加一次网络调用,并且需要修改获取session的方法, 从redis取数据比内存中慢得多。

最终选择统一存储。
统一存储,登录后将session存到redis中,并把放大cookie的作用域,使子域名父域名共享sessionId, 服务通过sessionId去Redis中取Session

SpringSession核心原理

整合Spring Sessioin
导入依赖—配置选择使用redis–设置session过期时间—配置redis访问—注解加上RedisSession
最好使用Json的序列化方式
改变cookie作用域,写个配置文件类

SpringSession源码… 主要用了装饰者模式

四、单点登录 SSO

4.1 单点登录简介

单点登录就是在多个系统中,用户只需一次登录,各个系统即可感知该用户已经登录。
使用SpringSession 达到了一个系统,多个微服务和子域共享Session的目的。
但是如果是多系统。同一个公司的不同系统,域名不同,也希望一个系统登陆,访问另一个系统也能是登录状态。
比如登录了微博,我们访问新浪网,也是登录的

4.2 SSO实现

核心: 三个系统即使域名不一样,想办法给三个系统同步同一个用户的票据

【分布式项目】认证服务中心、社交登录OAuth2.0、单点登录、分布式Session解决方案_第3张图片

关键核心:

  1. 给登录服务器留下登录痕迹
  2. 登录服务器重定向时附带登录成功的token,到url地址上
  3. 其他系统要处理url地址上的关键token,通过token获取到对应用户保存到自己session中
  4. 自己系统有了session就可以保持登录状态了

五、面试题,

①如果cookie被禁用了,怎么保存登录状态?

session在服务器内存,或者redis里面,可以通过sessionId找到session来保持登录状态,所以客户端得保持这个sessionId,以便交互的时候返回给服务器。可以使用cookie,这样每次交互会自动被带上。核心是与服务器交互的时候带上sessionId。还有以下方法:

  1. URL重写,把sessionId直接附加在URL路径后面。 【不太好, 所以页面的URL都得重写,且不能有静态页面】
  2. 把sessionId放到请求头里。

或者直接放弃session, 用Token (JWT) , 前端每次请求都带上token, 服务端解析token证明用户是合法的。JWT出现以后,使得单点登录更为简单了。

② 单点登录原理?OAuth2的流程?

见上文

③不同系统,不同域名如何感知到你的登录?

所有系统都去访问同一个的SSO系统【缺点SSO压力大】

【分布式项目】认证服务中心、社交登录OAuth2.0、单点登录、分布式Session解决方案_第4张图片

谢谢你们的点赞、收藏、关注。让我们一起进步,不断创作更优秀的文章
转载请注明地址:https://blog.csdn.net/weixin_44179010/article/details/124264393

你可能感兴趣的:(项目总结,分布式,后端)