为什么要引入单点登录？
最初我们刚学Java Web领域的SSM框架不久的时候，做出来的东西以xx管理系统为主，大致面向的都是企业级用户，但是企业级用户通常不会只使用一个系统，如果这个企业发展不错的话，这个企业就会慢慢的引入其他系统，比如再最开始的时候引入的就是办公自动化系统，用于实现报销、入职等自动化。这个企业属于制造型企业为了提升质量管理，又引入了质量管理系统。随着线上办公的普及，这个企业又采购了一个专门用于审批报销的系统，随着企业的发展，这个企业采购的系统就越来越多: 
对于一个同时要使用这些系统的人就很头疼了，他会有很多账号，上班的时候打开浏览器，同时打开这些系统，依次登上去。这些账号很让人头疼，我们自然会有这样一个愿景，这些系统都集成在办公系统中，然后我只用登录办公系统，其他系统像一个按钮一样集成在办公系统的页面中，我需要到质量管理系统中的时候就点击办公系统中的质量管理系统按钮就跳转到了质量管理系统，不用再登录。由此我们引出单点登录，这也就是单点登录(Single Sign On)。
单点登录的几个问题
我们来分析一下在从办公系统跳转到质量管理系统免除登录需要做些什么。我们可以预见的是不同的系统都有自己的登录验证机制，不可能大门敞开，将所有的系统登录验证关闭掉，因为软件系统的一些操纵都围绕着用户。有些信息只能系统中的某些用户来操纵。
常规情况下，登录操作的一般性设计就是用户在登录页输入账号和密码，当然现在也支持手机号验证码登录，系统在检查有此用户并且账号和密码输入正确的情况下，就会向客户端发放一个令牌，这个令牌你可以理解为通行证，客户端再次访问服务端资源的时候，在请求中放入首次成功登陆时服务端发放的令牌，服务端在校验令牌并通过令牌来判定当前用户是谁，向客户端返回数据。但是这里不同的系统发放令牌的方式又是不一样的，有的是Session-Cookie模式，有的是JWT模式。
除此之外不同的系统表的结构设计也是不相同的，两套系统内的密码也不相同，认证体系也不同，我们也不大可能在每个系统都做其他系统的应用的数据 备案，在由办公系统跳到质量管理系统的时候，办公系统的服务端返回前端账号和密码，前端自动的填充质量管理系统账号和密码，这显然不大安全，懂一点Web系统的人很容易就可以截获密码。最终的问题就出在认证上，我们可以认为每个系统都拥有一个认证处，不同的系统发放的通行证是不同的，两个系统没有互信。那我们自然会想能否有一个统一的认证中心呢？由认证中心统一发放一个令牌，各个系统信任这个由统一认证中心发发放的令牌，客户端在收到这个令牌之后就能实现在一个系统登录一次，在其他系统中免除登录。这也就要求每个应用系统支持认证中心的令牌，也就是在原来的登录基础上补充一种认证方式，或者说都采用一种方式。
单点登录的几种方式以及问题
上面的讨论可以认为是单点登录的一种实现方式，不贴近于技术，如果讨论的更贴近于技术一点，不用认证中心我们也可以实现单点登录。我们来回顾一下以前做的登录是借助于Cookie和Session来实现的, 根据用户输入的信息判定用户和密码输入正确, 将该用户的信息放入Session中，在用户再次访问服务端资源的时候，从Session中去获取该用户的信息，如果没有获取到该用户的信息就说明该用户没有登录，页面重定向到登录页面。
对于多系统来说，每个系统都有应用服务器，Session是独立的,Session是无法共享的，那我们做Session全局复制吗？ 这样搞完全同步有点分布式的感觉，网络并不完全可靠，如果追求强一致性，会比较影响性能。那大家将Session信息放入Redis中，这是个不错的建议，对于自己内部开发的系统来说，可以通过这种方式来解决Session共享。但是对于采购过来的系统呢，也接入Redis？尽管Redis很强大，但不加节制将Session都放入Redis，这样会不会有性能问题呢。
另一种通用的方式是开发一个认证中心，采购的系统对自身进行改造来支持认证中心所发放的令牌，用户在请求登录的时候， 检查没有登录的时候，跳转到应用中心上，在跳转认证中心的时候带上自己的地址，认证中心认证通过之后，返回token，跳转回去，即可实现登录。再次请求的时候，将认证中心返回的token带上，拦截器得到Token判断是否登录，相关的用户信息也由统一认证中心放入Redis中。这是实现单点登录的另一种方式。
说到单点登录，一般都会谈到CAS，注意这里的CAS 不是compare and swap的缩写，是Central Authentication Service(中心授权服务)的缩写。 那究竟是什么?
集中式认证服务（英语：Central Authentication Service，缩写CAS）是一种针对万维网的单点登录协议。它的目的是允许一个用户访问多个应用程序，而只需向认证服务器提供一次凭证（如用户名和密码）。这样用户不仅不需在登陆web应用程序时重复认证，而且这些应用程序也无法获得密码等敏感信息。“CAS”也指实现了该协议的软件包。 ---《维基百科》
这感觉就是我们上面讨论的认证中心，是的，集中式认证服务不仅仅是一个协议，而且还是一个开源项目，支持多种语言，多种协议。简单的说就是一个war包，提供了认证服务，我们稍加改造就能接入我们的业务系统，让我们的多系统支持单点登录。 我们举个例子来说明一下集中式认证服务网,假设我们现在有两个系统A和B,地址分别是www.aaa.com和www.bbb.com。认证中心: www.sso.com. 用户请求A系统，A系统发现当前用户还没有登录，于是重定向到认证中心,地址栏如下图所示:
- www.sso.com? name = www.aaa.com
认证中心发现用户还没有登录，就将用户引导至登录页面，用户输入必要信息进行登录的时候，会与认证中心建立全局会话(生成一份token, 写入到Cookie中,不懂这个token可以将token理解为通行证，我们的系统看到这个通行证才会放行。)，注意此时Cookie中的域名还是sso.com。
随后认证中心重定向回A系统，并把token携带回去给系统A, 重定向的地址如下:
接着系统 A去认证中心验证Token是否是合法的和正确的，如果正确，创建Session，进入系统。此时用户A已经成功登陆系统A了。假设用户在系统A中想进入系统B，系统B发现用户A并没有在我这里登录，于是又重定向到认证中心，将自己的地址作为参数，请求地址如下:
用户从系统A在经由认证中心登录的时候，Cookie已经保存在浏览器上了。此时从B系统到认证中心，认证中心就可以从Cookie中获取到Token，然后重定向回B系统就可以把Token携带回去给系统B。重定向的地址如下:
然后用户去认证中心验证这个token的合法性，如果合法，则B系统放行用户登录，创建Session。这个过程用户并不会有明显的感知，到此时，用户在B系统已经处于登录状态了。
总结一下
简而言之，多系统登录用户的信息和登录状态的共享就是单点登录要解决的问题，一个系统登录后的认证信息需要让另一个系统获取的到。对此我们可以采取将登录信息放入Redis中来实现信息共享，也可以做一个认证中心，由认证中心验证来统一验证。
