为了账号安全,请及时绑定邮箱和手机立即绑定

面试系列:单点登录的知识(一)

标签:
架构

大家好,我是车辙,由于目前接手的业务涉及到了单点登录,所以一直在疯狂的去补充这方面的知识。也写下了这篇面试形式的文章,写的不好大家轻点 Diss。

面试开始

在焦急的等待中,一位看上去比较年轻的小伙子走了过来。我心想:这么年轻,看来今天的面试稳了。“你好,我是今天的面试官,一位97年的架构师。我看你简历上写了精通单点登录,我们今天就聊聊这个吧”

什么是单点登录

这也太简单了。讲个自己的糗事,在我刚实习的时候,我曾经以为单点登录就是单用户登录,比如说我在一台手机上登录后,另一台手机再次登录就会把原先的那个给挤掉。因为这个在一次技术分享会上还出了大糗。

实际上,单点登录是指在多个应用系统中,用户只需要登录任意一个系统,就可以访问其他的互相信任的系统。比如说我在天猫登录后,在浏览器上输入淘宝的域名,你就已经登录成功了。

image.png

为什么需要单点登录

面试官:“你觉得为什么需要单点登录,或者说单点登录的价值体现在哪里”

为了方便,如果一款产品的用户体验很差劲,那么基本上是没有用户愿意持续使用的。

通过单点登录,可以让用户在多系统中灵活跳转而不必重新登录,能有效提升用户体验。就像我们杭州的最多跑一次。

常见的登录实现

面试官:那我们先来聊一下常见的登录是怎么做的?

这不就是我们大学时候教的内容么,首先我们后端有个拦截器,每次请求接口时都会在拦截器内部进行判断:根据Cookie中传递的SessionId判断用户信息是否已经保存在Session中。如果不存在,说明用户未登录,让浏览器跳转到登录页进行登录。

登录验证成功后,把用户信息写入到 服务器Session中。于是通过Cookie中的SessionId和服务器建立了会话。

并且一般来说,浏览器中的Cookie不会设置过期时间,而是在服务端的Session中设置,由服务端来控制用户的登录态。

image.png

单点登录的设计思路

面试官:有点东西哈,那么如果要你设计实现一个单点登录系统,有没有什么简单点的方案?

我:首先我们要了解,单点登录其实就是用户的登录态在多个系统间进行共享。我们可以这样思考,假如用户在 A系统 登录后,然后点击 B系统,能够把用户相关信息给带过去,然后在 B系统中判断存在用户信息, 从而进行登录。这样做对于用户来说是完全无感知的,只需要在系统层面帮助用户进行登录即可。

传递数据到前端还是后端

面试官:“既然是传递数据至 系统B,你觉得该把数据传递到 系统B 的浏览器前端页面还是后端服务器呢,或者说两者的实现方式有什么区别?”

我:如果是通过浏览器页面传递信息,前端拿到用户信息后,可以调用 B系统 服务端接口进行登录,与B系统建立会话。

image.png

如果是传递到 B系统 后端服务器,需要在服务器进行登录,然后带上用户信息重定向到B系统前端页面,这时候建立会话完成。

image.png

在前后端分离的情况下,我们一般采用第一种方式进行数据传递。

如何传递数据

面试官:“从你的两种方案中,不管是浏览器层面的跳转,还是后端重定向,都需要带上用户信息。如果是方式1,那么这个用户信息放在哪里呢,是URL链接还是其他地方”。

我:既然是通过浏览器传递数据,有两种方式,第一种是通过在Url上拼接参数,比如 http://www.baidu.com?userId=123

第二种是通过Cookie的形式传递,但是由于Cookie不能跨域,就导致了部分局限性。

为了体现对技术的追求,我偷偷的补充了一句:不过我发现在淘宝的Cookie中,能够看到天猫的domain,好像是用Jsonp实现的。

image.png

安全性如何保证

面试官点了点头,内心多少有点赞许了。接着问了面试中最常见的问题之一:不管是URL还是Cookie传递数据,你们如何保证数据的安全性呢?

身为一个对自我要求很高的程序员,这肯定难不倒我。保证数据的安全性总的来说有几种实现:

  1. 从软件层面上进行保证,比如说可见性等。
  2. 通过加密算法对数据进行加密。

因为从浏览器层面保证数据不可见不太现实,所以可以对数据进行加密,并且这个数据加解密的过程应该由服务端来实现

比如:用户在 系统A 登录后,系统A 的服务端通过某种加密算法以及某个秘钥对用户数据进行加密,接着返回给前端。系统A 页面跳转到系统B时带上这个加密信息,接着调用系统B服务端接口进行登录。系统B 通过解密数据获取登录者的用户信息进行登录即可。

image.png

你们的单点登录具体是如何实现的

“重头戏来了”,因为我们所有系统的顶级域名都是一样的,因此不会存在跨域问题。为了降低接入成本,我们采用的是 Cookie加密 的形式。

比如用户在 系统A 登录后,系统A会往浏览器中写入Cookie, Key 为userInfo,value值为用户A的accountId。当然这个accountId是加密过的。

然后用户在访问系统B的页面时,由于属于同一个顶级域名,会带上 Cookie。调用系统B接口时,判断 Cookie中存在用户信息,如果存在,通过Secret进行解密获取用户的accountId,随后把用户数据放到Session中,从而进行登录。

这样做还有一个好处就是:用户可以直接在浏览器中输入域名进行跳转,而不是需要在 系统A 点击跳转到系统B。毕竟一般的用户都是把链接保存在书签的。

image.png

加密的Secret是怎么实现的

我们的Secret采用的是系统约定的形式,我猜面试官肯定会想Secret全都一样会不会不安全。

这个值在系统中以加密的形式进行存储,并且使用的配置中心,再加上我们系统使用的是专用网络,基本不存在泄漏的风险。

有时候面试的时候,不要等面试官问的时候再说。你可以提前预判他要问的问题,这样在他心里能加不少分呢。

使用Cookie 可能会存在被攻击的风险,你知道哪些吗

面试官说到这神情有点异样,莫非它以前经历过?

使用Cookie存储的方式可能会受到Xss攻击,也就是攻击者在页面上注入恶意脚本,然后在浏览器上运行这段脚本,从而获取用户的数据,比如Cookie等,危害数据安全。这有点像我们后端的SQL注入

所以我们的系统在设置用户Cookie时都会设置 HttpOnly=true,这样通过js脚本将无法读取到cookie信息,增强了使用Cookie的安全性。

另外除了Xss攻击外,还会存在Csrf攻击,也就是跨站请求伪造,攻击者一般会诱导用户进入第三方网站。然后在第三方网站中,通过比较吸引人的链接让用户点击。从而冒充用户对被攻击的网站执行某项操作的目的。

我怎么听起来有点像背的,你能举个例子解释下吗

“事也太多了吧,谁面试的时候不准备下八股文背诵”,我默默的竖起了中指。

清了下嗓子,比如说某银行的官网使用的是Cookie-Session登录机制。那么用户在工商银行登录之后,浏览器上会保存有用户的SessionId。之后用户访问了第三方网站,网站页面上写着“跳楼大甩卖,100元一枚比特币,点击购买”。

image.png

你明知道是假的,但还是忍不住。你一点击,脑海里已经幻想着比特币到账100枚,却没想到收到了短信;“您的银行账户转账10000元”。

你突然两眼一黑,战战兢兢的打开链接地址,没想到链接地址是:“icbc.com?transfer=10000&userId=坏蛋”,它会向银行发出转账请求。并且由于你之前登录过银行,这个请求还会带上Cookie,从而让银行认为这是你发出的“正确行为”。

我顺道还聊了下解决方式:业界会使用 CSRF Token 的方式解决。只不过这个成本较高,所以我们就使用了双重Cookie验证,再加上我们的网络是专用网络,也能提高安全问题。

这块内容,美团技术博客的文章都提到了,没看的同学建议去看下,上文给了链接哦。

因为你是Cookie,如果其他人拿到了你的用户信息怎么办

emm,面试官你的问题很刁钻嘛。事实上传统的 session+cookie 方案,如果泄露了sessionId,别人同样可以盗用你的身份,就像Csrf攻击。

就像前端页面的真人验证一样,只要你们的信息是保存在前端页面的,只要能看你的前端代码,不管使用的加密逻辑再复杂,总是能被人破解的。

我之前有个同学,他们公司有部分业务是搞爬虫的,叫 MoXieKeJi。 他们公司就是爬取其他公司的个人征信、个人信息,然后给第三方公司提供风控数据。支付宝的安全做的还不错吧,照样被他们把用户的芝麻信用、蚂蚁花呗的数据搞出来了。蚂蚁改一次逻辑,他们也跟着改,最后蚂蚁发了律师函,后面整个公司都被请去喝茶了。

所以我觉得考虑这个问题,还不如考虑下别人为什么能够拿到你的信息。比如说使用Https

不过要是攻击者直接打开了我的浏览器,把我的Cookie信息拿走,那我就真的无能为力了。

用户登录的时效性怎么保证

面试官:在这种方式下,用户登录的时效性你们是怎么保证的,不管是对当前系统还是多系统的维度下。

我:在单系统条件下,如果是标准的 Cookie-Session 机制,用户登录后调用接口,这个 Session 会进行续签,从而让会话保持下去。会话的生命周期变成了主要由服务端来保证

但是通过目前的这种形式,通过Cookie中是否存在用户信息判断是否登录,会出现一个情况就是只要这个用户信息也就是Cookie一直存在,那么用户就永远不会退出。(因为我们只会对数据进行解密,并且用户在登录后,Cookie并不会设置有效期),也就是说这个会话的生命周期变成了由 Cookie 来保证。

所以我们有两种方案,一种是对 Cookie 添加过期时间,比如 30 分钟,只要Cookie消失了,说明用户登录状态失效。第二种是在userInfo这个CookieValue值中添加过期信息,然后每次接口调用时服务端判断是否超时。

你觉得这种方案可行吗

我好像看见了面试官嘴角的微笑,不急不慢的说到。

但是问题点在于续签问题,这两种方式不可避免的都需要刷新,也就是说用户只要请求后端服务,都需要重新设置Cookie的过期时间或者修改Value的值。这个相对的就比较蠢了,而且还会有性能问题。

所以我们项目的目前方案是由Cookie来保证这个会话的生命周期,并且不进行续签

更好的解决方案

面试官:你们的单点登录方案其实就是依靠JWT设计实现的。但是通过Cookie来保证会话的生命周期终究不是个特别好的思路。有没有更好的方案,比如说由后端来控制会话的生命周期?

我:就知道你要问这个。我们可以把系统A 和 系统B 的用户会话信息由服务端控制,进行统一控制。比如使用Spring-Session方案,使用同一个 Redis。这样的话用户在系统A登录后,将用户会话信息保存在Redis中。然后在打开系统B时,
因为Cookie同域,调用 系统B 接口时,上传的是同一个SessionId,系统B从Redis中判断用户已经登录了,返回登录成功,进行续签。

image.png

有优化空间没

面试官:这样一来,系统A 和 系统B 都会存在很多相同的后端代码,一个改动其他系统也要跟着改。到时候如果有很多个系统,修改成本是不是太大了?

我:确实是的。所以我们可以把 系统A 和 系统B 的那些代码搞成个服务端的认证中心,这样一来不是方便多了。而且Cookie始终有着跨域的问题。按照这个思路,我是不是可以把前端页面也搞成同一个,形成认证中心的前端页面。

“等等,这不就是CAS的设计思路嘛”

image.png

面试结束

面试官:“好小子,领悟力可以呀,有当架构师的潜力,明天就来上班吧。对了,到时候我们再聊聊 CAS 的问题”

总结

关于单点登录的内容,这一节就暂时到这啦。下一章我们来聊下这节末尾提到的CAS以及相似的Oauth2

补充一点:我们在面试的时候,对于技术思路一定要有连贯性,层层挖掘深入,特别是大厂的那些面试官。比如JVM类加载的问题,可能流程是这样的:

image.png

我当初就是被这一套组合拳打的满地找牙,还有最好是结合自己做的项目。有些同学可能会觉得没接触过,你可以把这些技术给带入进去,进行自我的模拟面试,只要逻辑清晰,有自己的理解和思考,面试成绩应该都不会太差。

我是车辙,掘金小册《SkyWalking》作者,一名常被HR调侃为XX杨洋的互联网打工人。

点击查看更多内容
TA 点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
  • 推荐
  • 评论
  • 收藏
  • 共同学习,写下你的评论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消