单点登录 在大型网站里使用得非常频繁，例如，阿里旗下有淘宝、 天猫 、支付宝, 阿里巴巴 ，阿里妈妈，阿里妹妹等网站，还有背后的成百上千的子系统，用户一次操作或交易可能涉及到几十个子系统的协作，如果每个子系统都需要用户认证，不仅用户会疯掉，各子系统也会为这种重复认证授权的逻辑搞疯掉。
淘宝 天猫 支付宝 钉钉 都是采用统一的支付宝和淘宝账号！
==所以，单点登录要解决的就是，用户只需要登录一次就可以访问所有相互信任的应用系统。==
1、 SSO 概念
单点登录（Single Sign On），简称为 SSO ，是目前比较流行的企业业务整合的解决方案之一。SSO 并不能算是一种架构，只能说是一个解决方案。SSO核心意义就一句话：==一处登录，处处登录；一处注销，处处注销。==就是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统，即用户只需要记住一组用户名和密码就可以登录所有有权限的系统。
较大的企业内部，一般都有很多的业务支持系统为其提供相应的管理和IT服务。这些不同的系统往往是在不同的时期建设起来的，运行在不同的平台上；企业应用集成可以在不同层面上进行：例如在数据存储层面 上的“数据大集中”，在传输层面上的“通用数据交换平台”，在应用层面上的“业务流程整合”，和用户界面上的“通用企业门户”等等。事实上，还用一个层面 上的集成变得越来越重要，那就是“身份认证”的整合，也就是“单点登录”。
另外，使用“单点登录”还是 SOA 时代的需求之一。在面向服务的架构中，服务和服务之间，程序和程序之间的通讯大量存在，服务之间的安全认证是SOA应用的难点之一，应此建立“单点登录”的系统体系能够大大简化SOA的安全问题，提高服务之间的合作效率。
单点登录的机制其实是比较简单的，用一个现实中的例子做比较。 颐和园 是北京著名的旅游景点，也是我常去的地方。在颐和园内部有许多独立的景点，例如“苏州街”、“佛香阁”和“德和园”，都可以在各个景点门口单独买票。很多游客需要游玩所有德景点，这种买票方式很不方便，需要在每个景点门口排队买票，钱包拿 进拿出的，容易丢失，很不安全。于是绝大多数游客选择在大门口买一张通票（也叫套票），就可以玩遍所有的景点而不需要重新再买票。他们只需要在每个景点门 口出示一下刚才买的套票就能够被允许进入每个独立的景点。
单点登录的机制也一样，如下图所示，当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录（1）；根据用户提供的登录信息， 认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据－－ticket（2）；用户再访问别的应用的时候（3，5）就会将这个ticket 带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行效验，检查ticket的合法性（4，6）。如果通过效验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。
2、简谈SSO的发展
早期的单机部署
早期我们开发web应用都是所有的包放在一起打成一个war包放入 tomcat 容器来运行的,所有的功能,所有的业务,后台管理,门户界面,都是由这一个war来支持的,这样的单应用,也称之为单体应用,因为十分不好扩展和拆分。
在单体应用下,用户的登录以及权限就显得十分简单：过滤器,用户登录成功后,把相关信息放入会话中,HTTP维护这个会话,再每次用户请求服务器的时候来验证这个会话即可
验证登录的这个会话就是 Session ,维护了用户状态,也就是所谓的HTTP有状态协议,我们经常可以在浏览器中看到JSESSIONID,这个就是用来维持这个关系的key。
分布式集群部署
由于网站的访问量越来也大，单机部署已经是巨大瓶颈，所以才有了后来的分布式集群部署。例如：如果引入集群的概念,1单应用可能重新部署在3台tomcat以上服务器,使用 nginx 来实现 反向代理 , 此时,这个session就无法在这3台tomcat上共享,用户信息会丢失，所以不得不考虑多服务器之间的session同步问题，这就是单点登录的来源。
cookie 单点登录
单点登录的实现方案，一般就包含以下三种：
- Cookies
- Session同步
- 分布式Session方式
目前的大型网站都是采用分布式Session的方式。我先从cookie的实现谈起，你就能很清楚的知道为什么需要分布式session方式实现单点登录。
基于Cookie的单点登录
最简单的单点登录实现方式，是使用cookie作为媒介，存放用户凭证。 用户登录父应用之后，应用返回一个加密的cookie，当用户访问子应用的时候，携带上这个cookie，授权应用解密cookie并进行校验，校验通过则登录当前用户。
不难发现以上方式把信任存储在客户端的Cookie中，这种方式很容易令人质疑：
- Cookie不安全
- 不能跨域实现免登
对于第一个问题，通过加密Cookie可以保证安全性，当然这是在源代码不泄露的前提下。如果Cookie的加密算法泄露，攻击者通过伪造Cookie则可以伪造特定用户身份，这是很危险的。
对于第二个问题，不能跨域实现免登更是硬伤。所以，才有了以下的分布式session方案。
分布式session单点登录
例如，阿里有很多系统分割为多个子系统，独立部署后，不可避免的会遇到会话管理的问题，类似这样的电商网站一般采用分布式Session实现。
再进一步可以根据分布式Session+redis，建立完善的单点登录或账户管理系统。
流程运行：
- 用户第一次登录时，将会话信息（用户Id和用户信息），比如以用户Id为Key，写入分布式Session；
- 用户再次登录时，获取分布式Session，是否有会话信息，如果没有则调到登录页；
- 一般采用Cache 中间件 实现，建议使用Redis，因此它有 持久化 功能，方便分布式Session宕机后，可以从持久化存储中加载会话信息；
- 存入会话时，可以设置会话保持的时间，比如15分钟，超过后自动超时；
结合Cache中间件实现的分布式Session，可以很好的模拟Session会话。大家觉得这个课程对大家有帮助吗？敬请关注，下一个文章告诉大家具体的解决方案！
