为什么需要单点登录
单点登录SSO(Single Sign On)说得简单点就是在一个多系统共存的环境下,用户在一处登录后,就不用在其他系统中登录,也就是用户的一次登录能得到其他所有系统的信任。
单点登录在大型网站里使用得非常频繁,例如,阿里旗下有淘宝、天猫、支付宝等网站,还有背后的成百上千的子系统,用户一次操作或交易可能涉及到几十个子系统的协作,如果每个子系统都需要用户认证,不仅用户会疯掉,各子系统也会为这种重复认证授权的逻辑搞疯掉。
所以,单点登录要解决的就是,用户只需要登录一次就可以访问所有相互信任的应用系统。
单点登录的来源
1.早期的单机部署:web单系统应用
早期我们开发web应用都是所有的包放在一起打成一个war包放入tomcat容器来运行的,所有的功能,所有的业务,后台管理,门户界面,都是由这一个war来支持的,这样的单应用,也称之为巨石应用,因为十分不好扩展和拆分。
在巨石应用下,用户的登录以及权限就显得十分简单,用户登录成功后,把相关信息放入会话中,HTTP维护这个会话,再每次用户请求服务器的时候来验证这个会话即可,大致可以用下图来表示:
验证登录的这个会话就是session,维护了用户状态,也就是所谓的HTTP有状态协议,我们经常可以在浏览器中看到JSESSIONID,这个就是用来维持这个关系的key。
2.分布式集群部署
由于网站的访问量越来也大,单机部署已经是巨大瓶颈,所以才有了后来的分布式集群部署。例如:如果引入集群的概念,1单应用可能重新部署在3台tomcat以上服务器,使用nginx来实现反向代理, 此时,这个session就无法在这3台tomcat上共享,用户信息会丢失,所以不得不考虑多服务器之间的session同步问题,这就是单点登录的来源。
单点登录的原理和实现
单点登录的实现方案,一般就包含:Cookies,Session同步,分布式Session方式,目前的大型网站都是采用分布式Session的方式。我先从cookie的实现谈起,你就能很清楚的知道为什么需要分布式session方式实现单点登录。
1.基于Cookie的单点登录
最简单的单点登录实现方式,是使用cookie作为媒介,存放用户凭证。 用户登录父应用之后,应用返回一个加密的cookie,当用户访问子应用的时候,携带上这个cookie,授权应用解密cookie并进行校验,校验通过则登录当前用户。
不难发现以上方式把信任存储在客户端的Cookie中,这种方式很容易令人质疑:
- Cookie不安全
- 不能跨域实现免登
对于第一个问题,通过加密Cookie可以保证安全性,当然这是在源代码不泄露的前提下。如果Cookie的加密算法泄露,攻击者通过伪造Cookie则可以伪造特定用户身份,这是很危险的。 对于第二个问题,不能跨域实现免登更是硬伤。所以,才有了以下的分布式session方案。
2.分布式session方式实现单点登录
例如阿里有很多系统分割为多个子系统,独立部署后,不可避免的会遇到会话管理的问题,类似这样的电商网站一般采用分布式Session实现。
再进一步可以根据分布式Session,建立完善的单点登录或账户管理系统。
流程运行:
(1) 用户第一次登录时,将会话信息(用户Id和用户信息),比如以用户Id为Key,写入分布式Session;
(2) 用户再次登录时,获取分布式Session,是否有会话信息,如果没有则调到登录页;
(3) 一般采用Cache中间件实现,建议使用Redis,因此它有持久化功能,方便分布式Session宕机后,可以从持久化存储中加载会话信息;
(4) 存入会话时,可以设置会话保持的时间,比如15分钟,超过后自动超时;
结合Cache中间件,实现的分布式Session,可以很好的模拟Session会话。
总结:
以上分别从单点登录的原理、来源、实现机制来完整的解读单点登录。
实现单点登录说到底就是要解决如何产生和存储那个信任,再就是其他系统如何验证这个信任的有效性,因此要点也就以下两个:
- 存储信任
- 验证信任
存储信任建议可以采用分布式文件存储redis来实现。
作者简介
陈睿|mikechen,10年+大厂架构经验,BAT资深面试官,就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注作者「mikechen」公众号,获取更多技术干货!
后台回复【架构】,即可获取《阿里架构师进阶专题全部合集》,后台回复【面试】即可获取《史上最全阿里Java面试题总结》
这个只是讲了轮廓,需要细节
后面我再详细介绍一次单点登录包括使用细节。
应该使用JWT来实现单点登录吧
话说好像还是没解决跨域问题吧
话说,你这图画的有问题吧? 不是登陆成功才创建的会话,是访问服务器的时候已经创建会话,登陆成功后把相关信息,写入会话里