面试系列：单点登录的知识（一）
| 阿里云国内75折 回扣 微信号：monov8 |
| 阿里云国际，腾讯云国际，低至75折。AWS 93折 免费开户实名账号 代冲值 优惠多多 微信号：monov8 飞机：@monov6 |
大家好我是车辙由于目前接手的业务涉及到了单点登录所以一直在疯狂的去补充这方面的知识。也写下了这篇面试形式的文章写的不好大家轻点 Diss。
面试开始
在焦急的等待中一位看上去比较年轻的小伙子走了过来。我心想：这么年轻看来今天的面试稳了。“你好我是今天的面试官一位97年的架构师。我看你简历上写了精通单点登录我们今天就聊聊这个吧”
什么是单点登录
这也太简单了。讲个自己的糗事在我刚实习的时候我曾经以为单点登录就是单用户登录比如说我在一台手机上登录后另一台手机再次登录就会把原先的那个给挤掉。因为这个在一次技术分享会上还出了大糗。
实际上单点登录是指在多个应用系统中用户只需要登录任意一个系统就可以访问其他的互相信任的系统。比如说我在天猫登录后在浏览器上输入淘宝的域名你就已经登录成功了。
为什么需要单点登录
面试官：“你觉得为什么需要单点登录或者说单点登录的价值体现在哪里”
为了方便如果一款产品的用户体验很差劲那么基本上是没有用户愿意持续使用的。
通过单点登录可以让用户在多系统中灵活跳转而不必重新登录能有效提升用户体验。就像我们杭州的最多跑一次。
常见的登录实现
面试官：那我们先来聊一下常见的登录是怎么做的？
这不就是我们大学时候教的内容么首先我们后端有个拦截器每次请求接口时都会在拦截器内部进行判断：根据Cookie中传递的SessionId判断用户信息是否已经保存在Session中。如果不存在说明用户未登录让浏览器跳转到登录页进行登录。
登录验证成功后把用户信息写入到 服务器Session中。于是通过Cookie中的SessionId和服务器建立了会话。
并且一般来说浏览器中的Cookie不会设置过期时间而是在服务端的Session中设置由服务端来控制用户的登录态。
单点登录的设计思路
面试官：有点东西哈那么如果要你设计实现一个单点登录系统有没有什么简单点的方案？
我：首先我们要了解单点登录其实就是用户的登录态在多个系统间进行共享。我们可以这样思考假如用户在 A系统 登录后然后点击 B系统能够把用户相关信息给带过去然后在 B系统中判断存在用户信息 从而进行登录。这样做对于用户来说是完全无感知的只需要在系统层面帮助用户进行登录即可。
传递数据到前端还是后端
面试官：“既然是传递数据至 系统B你觉得该把数据传递到 系统B 的浏览器前端页面还是后端服务器呢或者说两者的实现方式有什么区别？”
我：如果是通过浏览器页面传递信息前端拿到用户信息后可以调用 B系统 服务端接口进行登录与B系统建立会话。
如果是传递到 B系统 后端服务器需要在服务器进行登录然后带上用户信息重定向到B系统前端页面这时候建立会话完成。
在前后端分离的情况下我们一般采用第一种方式进行数据传递。
如何传递数据
面试官：“从你的两种方案中不管是浏览器层面的跳转还是后端重定向都需要带上用户信息。如果是方式1那么这个用户信息放在哪里呢是URL链接还是其他地方”。
我：既然是通过浏览器传递数据有两种方式第一种是通过在Url上拼接参数比如 http://www.baidu.com?userId=123 。
第二种是通过Cookie的形式传递但是由于Cookie不能跨域就导致了部分局限性。
为了体现对技术的追求我偷偷的补充了一句：不过我发现在淘宝的Cookie中能够看到天猫的domain好像是用Jsonp实现的。
安全性如何保证
面试官点了点头内心多少有点赞许了。接着问了面试中最常见的问题之一：不管是URL还是Cookie传递数据你们如何保证数据的安全性呢？
身为一个对自我要求很高的程序员这肯定难不倒我。保证数据的安全性总的来说有几种实现：
- 从软件层面上进行保证比如说可见性等。
- 通过加密算法对数据进行加密。
因为从浏览器层面保证数据不可见不太现实所以可以对数据进行加密并且这个数据加解密的过程应该由服务端来实现。
比如：用户在 系统A 登录后系统A 的服务端通过某种加密算法以及某个秘钥对用户数据进行加密接着返回给前端。系统A 页面跳转到系统B时带上这个加密信息接着调用系统B服务端接口进行登录。系统B 通过解密数据获取登录者的用户信息进行登录即可。
时序图是用代码画的想了解的访问我之前的文章:这是啥操作用代码能画这样的图
你们的单点登录具体是如何实现的
“重头戏来了”因为我们所有系统的顶级域名都是一样的因此不会存在跨域问题。为了降低接入成本我们采用的是 Cookie加密 的形式。
比如用户在 系统A 登录后系统A会往浏览器中写入Cookie, Key 为userInfovalue值为用户A的accountId。当然这个accountId是加密过的。
然后用户在访问系统B的页面时由于属于同一个顶级域名会带上 Cookie。调用系统B接口时判断 Cookie中存在用户信息如果存在通过Secret进行解密获取用户的accountId随后把用户数据放到Session中从而进行登录。
这样做还有一个好处就是：用户可以直接在浏览器中输入域名进行跳转而不是需要在 系统A 点击跳转到系统B。毕竟一般的用户都是把链接保存在书签的。
加密的Secret是怎么实现的
我们的Secret采用的是系统约定的形式我猜面试官肯定会想Secret全都一样会不会不安全。
这个值在系统中以加密的形式进行存储并且使用的配置中心再加上我们系统使用的是专用网络基本不存在泄漏的风险。
有时候面试的时候不要等面试官问的时候再说。你可以提前预判他要问的问题这样在他心里能加不少分呢。
使用Cookie 可能会存在被攻击的风险你知道哪些吗
面试官说到这神情有点异样莫非它以前经历过？
使用Cookie存储的方式可能会受到Xss攻击也就是攻击者在页面上注入恶意脚本然后在浏览器上运行这段脚本从而获取用户的数据比如Cookie等危害数据安全。这有点像我们后端的SQL注入。
所以我们的系统在设置用户Cookie时都会设置 HttpOnly=true这样通过js脚本将无法读取到cookie信息增强了使用Cookie的安全性。
另外除了Xss攻击外还会存在Csrf攻击也就是跨站请求伪造攻击者一般会诱导用户进入第三方网站。然后在第三方网站中通过比较吸引人的链接让用户点击。从而冒充用户对被攻击的网站执行某项操作的目的。
关于Xss 和 Csrf 你可以去看美团技术博客的文章链接我都帮你们准备好了
如何防止XSS攻击？
我怎么听起来有点像背的你能举个例子解释下吗
“事也太多了吧谁面试的时候不准备下八股文背诵”我默默的竖起了中指。
清了下嗓子比如说某银行的官网使用的是Cookie-Session登录机制。那么用户在工商银行登录之后浏览器上会保存有用户的SessionId。之后用户访问了第三方网站网站页面上写着“跳楼大甩卖100元一枚比特币点击购买”。
你明知道是假的但还是忍不住。你一点击脑海里已经幻想着比特币到账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这个Cookie的Value值中添加过期信息然后每次接口调用时服务端判断是否超时。
你觉得这种方案可行吗
我好像看见了面试官嘴角的微笑,不急不慢的说到。
但是问题点在于续签问题这两种方式不可避免的都需要刷新也就是说用户只要请求后端服务都需要重新设置Cookie的过期时间或者修改Value的值。这个相对的就比较蠢了而且还会有性能问题。
所以我们项目的目前方案是由Cookie来保证这个会话的生命周期并且不进行续签。
更好的解决方案
面试官：你们的单点登录方案其实就是依靠JWT设计实现的。但是通过Cookie来保证会话的生命周期终究不是个特别好的思路。有没有更好的方案比如说由后端来控制会话的生命周期？
我：就知道你要问这个。我们可以把系统A 和 系统B 的用户会话信息由服务端控制进行统一控制。比如使用Spring-Session方案使用同一个 Redis。这样的话用户在系统A登录后将用户会话信息保存在Redis中。然后在打开系统B时
因为Cookie同域调用 系统B 接口时上传的是同一个SessionId系统B从Redis中判断用户已经登录了返回登录成功进行续签。
有优化空间没
面试官：这样一来系统A 和 系统B 都会存在很多相同的后端代码一个改动其他系统也要跟着改。到时候如果有很多个系统修改成本是不是太大了？
我：确实是的。所以我们可以把 系统A 和 系统B 的那些代码搞成个服务端的认证中心这样一来不是方便多了。而且Cookie始终有着跨域的问题。按照这个思路我是不是可以把前端页面也搞成同一个形成认证中心的前端页面。
“等等这不就是CAS的设计思路嘛”
面试结束
面试官：“好小子领悟力可以呀有当架构师的潜力明天就来上班吧。对了到时候我们再聊聊 CAS 的问题”
总结
关于单点登录的内容这一节就暂时到这啦。下一章我们来聊下这节末尾提到的CAS以及相似的Oauth2。
补充一点：我们在面试的时候对于技术思路一定要有连贯性层层挖掘深入特别是大厂的那些面试官。比如JVM类加载的问题可能流程是这样的：
我当初就是被这一套组合拳打的满地找牙还有最好是结合自己做的项目。有些同学可能会觉得没接触过你可以把这些技术给带入进去进行自我的模拟面试只要逻辑清晰有自己的理解和思考面试成绩应该都不会太差。
如果这篇文章对您有所帮助可以关住《车辙的编程学习圈》。
我是车辙掘金小册《SkyWalking》作者一名常被HR调侃为XX杨洋的互联网打工人。