首页手记面试系列：单点登录的知识（一）

面试系列：单点登录的知识（一）

标签：

架构

大家好，我是车辙，由于目前接手的业务涉及到了单点登录，所以一直在疯狂的去补充这方面的知识。也写下了这篇面试形式的文章，写的不好大家轻点 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 为userInfo，value值为用户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攻击，也就是跨站请求伪造，攻击者一般会诱导用户进入第三方网站。然后在第三方网站中，通过比较吸引人的链接让用户点击。从而冒充用户对被攻击的网站执行某项操作的目的。

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

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

清了下嗓子，比如说某银行的官网使用的是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中判断用户已经登录了，返回登录成功，进行续签。