大家好，我是车辙，因为现在接手的事务触及到了单点登录，所以一向在张狂的去弥补这方面的知识。也写下了这篇面试方法的文章，写的欠好大家轻点 Diss。
面试开始
在着急的等待中，一位看上去比较年青的小伙子走了过来。我心想：这么年青，看来今日的面试稳了。“你好，我是今日的面试官，一位97年的架构师。我看你简历上写了精通单点登录，咱们今日就聊聊这个吧”
什么是单点登录
这也太简单了。讲个自己的糗事，在我刚实习的时分，我曾经以为单点登录便是单用户登录，比方说我在一台手机上登录后，另一台手机再次登录就会把原先的那个给挤掉。因为这个在一次技能分享会上还出了大糗。
实际上，单点登录是指在多个运用体系中，用户只需求登录恣意一个体系，就能够拜访其他的相互信赖的体系。比方说我在天猫登录后，在浏览器上输入淘宝的域名，你就现已登录成功了。
为什么需求单点登录
面试官：“你觉得为什么需求单点登录，或许说单点登录的价值表现在哪里”
为了方便，假如一款产品的用户体验很差劲，那么基本上是没有用户乐意持续运用的。
经过单点登录，能够让用户在多体系中灵敏跳转而不用从头登录，能有用提升用户体验。就像咱们杭州的最多跑一次。
常见的登录完成
面试官：那咱们先来聊一下常见的登录是怎样做的？
这不便是咱们大学时分教的内容么，首先咱们后端有个拦截器，每次恳求接口时都会在拦截器内部进行判别：根据Cookie中传递的SessionId判别用户信息是否现已保存在Session中。假如不存在，阐明用户未登录，让浏览器跳转到登录页进行登录。
登录验证成功后，把用户信息写入到 服务器Session中。于是经过Cookie中的SessionId和服务器树立了会话。
并且一般来说，浏览器中的Cookie不会设置过期时刻，而是在服务端的Session中设置，由服务端来操控用户的登录态。
单点登录的规划思路
面试官：有点东西哈，那么假如要你规划完成一个单点登录体系，有没有什么简单点的计划？
我：首先咱们要了解，单点登录其实便是用户的登录态在多个体系间进行共享。咱们能够这样考虑，假设用户在 A体系 登录后，然后点击 B体系，能够把用户相关信息给带过去，然后在 B体系中判别存在用户信息， 然后进行登录。这样做关于用户来说是完全无感知的，只需求在体系层面帮助用户进行登录即可。
传递数据到前端仍是后端
面试官：”既然是传递数据至 体系B，你觉得该把数据传递到 体系B 的浏览器前端页面仍是后端服务器呢，或许说两者的完成方法有什么区别？”
我：假如是经过浏览器页面传递信息，前端拿到用户信息后，能够调用 B体系 服务端接口进行登录，与B体系树立会话。
假如是传递到 B体系 后端服务器，需求在服务器进行登录，然后带上用户信息重定向到B体系前端页面，这时分树立会话完成。
在前后端别离的状况下，咱们一般采用第一种方法进行数据传递。
怎么传递数据
面试官：“从你的两种计划中，不管是浏览器层面的跳转，仍是后端重定向，都需求带上用户信息。假如是方法1，那么这个用户信息放在哪里呢，是URL链接仍是其他地方”。
我：既然是经过浏览器传递数据，有两种方法，第一种是经过在Url上拼接参数，比方 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进犯，也便是跨站恳求假造，进犯者一般会诱导用户进入第三方网站。然后在第三方网站中，经过比较吸引人的链接让用户点击。然后假充用户对被进犯的网站履行某项操作的意图。
关于Xss 和 Csrf 你能够去看美团技能博客的文章，链接我都帮你们准备好了
怎么防止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来确保会话的生命周期毕竟不是个特别好的思路。有没有更好的计划，比方说由后端来操控会话的生命周期？
# JSON Web Token – 在Web运用间安全地传递信息
我：就知道你要问这个。咱们能够把体系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杨洋的互联网打工人。
