什么是单点登录？ 在企业发展初期，企业使用的系统很少，通常只有一个或两个，每个系统都有自己的登录模块，运营者每天都用自己的帐户登录，非常方便。
但是，随着企业的发展，使用的系统越来越多，运营者在操作不同的系统时，需要多次登录，而且每个系统的账户都不同。 这对运营者来说
对我来说很不方便。 于是，我想是不是可以登录一个系统，而不用登录其他系统。 这就是单点登录需要解决的问题。
单点登录英文全名Single Sign On，简称SSO。 其解释如下：在多个应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。
如图所示，有四个系统： APP 1、APP 2、APP 3和SSO。 APP 1、APP 2和APP 3没有登录模块，而SSO只有登录模块，没有其他业务模块。 如果需要登录到APP 1、APP 2和APP 3，请跳至SSO系统、SSO系统或SSO，这完全符合单点登录(SSO )的定义。
技术实现在说单点登录(SSO )技术的实现之前，先谈谈常见的登录认证机制吧。
如上图所示，通过浏览器访问APP应用程序。 此APP应用程序需要登录。 填写用户名和密码后，完成登录认证。 此时，我们将此用户的会话的登录状态标记为“是”(已登录)，同时将Cookie写入浏览器(浏览器)。 此Cookie是此用户的唯一标识符。 下次访问此APP时，请带上此cookie作为请求。 服务器将根据此cookie找到相应的session，并确定此用户是否在session中登录。 如果没有特殊配置，则此Cookie的名称称为jsessionid，并且值在服务器上是唯一的。
同一域下的一次登录一个企业通常只有一个域名，并根据二级域名区分不同的系统。 例如，有两个业务系统：域名a.com，app1.a.com和app2.a.com。 要进行单点登录(SSO )，需要一个名为sso.a.com的登录系统。
登录sso.a.com后，app1.a.com和app2.a.com也将登录。 在上述登录认证机制中，虽然登录了sso.a.com，但实际上sso.a.com的服务端session中记录了登录状态，Cookie写在浏览器端(Browser )的sso.a.com中那么，怎样才能让app1.a.com和app2.a.com登录？ 这里有两个问题：
Cookie不能跨越域。 我们Cookie的域属性是sso.a.com，不能向app1.a.com和app2.a.com发送请求。 so、app1和app2是不同的APP应用，它们的session存在于自己的APP应用中，并且不被共享。
那么如何解决这两个问题呢？ 对于第一个问题，sso登录后，可以将Cookie的域设置为顶级域，即. a.com。 这样，所有子域的系统都可以访问顶级域的Cookie。我们在设置Cookie时，只能设置顶域和自己的域，不能设置其他的域。比如：我们不能在自己的系统中给baidu.com的域设置Cookie。
饼干的问题解决了，来看看session的问题吧。 我们登录了sso系统，这时又访问了app1，把饼干也带到了app1的服务端(Server )。 app1的服务端如何找到与此cookie对应的Session？ 这里，如图所示，共享三个系统的Session。 共享会话的解决方案有很多，例如Spring-Session。 这样也解决了第二个问题。
实现了在该域的单点登录。但这还不是真正的单点登录。
不同域的单点登录和同一个域的单点登录是Cookie顶级域特性的巧妙利用。 如果是不同的域呢？ 不同的域之间不共享Cookie。 我该怎么办？
这里介绍的是单点登录的标准流程——cas流程。
上图为CAS官网标准流程，具体流程如下：
用户访问app系统。 app系统需要登录，但用户当前没有登录。 跳转到CAS server (即SSO登录系统)，也不登录以后图中的CAS Server我们统一叫做SSO系统。SSO系统，弹出用户登录页面。 用户填写用户名、密码，SSO系统进行认证后，将登录状态写入SSO的session，并在浏览器(Browser )中写入SSO域下的Cookie。 SSO系统登录完成后，将生成服务工具包(ST )，跳转到app系统，并将ST作为参数传递给app系统。 获得ST后，APP从后台向SSO发送请求，验证ST是否有效。 认证成功后，app系统将登录状态写入session，并设置app域下的Cookie。 这样，域间单点登录就完成了。 稍后访问app系统时，app将登录。 接下来，我们来看看访问app2系统时的流程。
用户访问
问app2系统，app2系统没有登录，跳转到SSO。由于SSO已经登录了，不需要重新登录认证。SSO生成ST，浏览器跳转到app2系统，并将ST作为参数传递给app2。app2拿到ST，后台访问SSO，验证ST是否有效。验证成功后，app2将登录状态写入session，并在app2域下写入Cookie。这样，app2系统不需要走登录流程，就已经是登录了。SSO，app和app2在不同的域，它们之间的session不共享也是没问题的。
有的同学问我，SSO系统登录后，跳回原业务系统时，带了个参数ST，业务系统还要拿ST再次访问SSO进行验证，觉得这个步骤有点多余。他想SSO登录认证通过后，通过回调地址将用户信息返回给原业务系统，原业务系统直接设置登录状态，这样流程简单，也完成了登录，不是很好吗？
其实这样问题时很严重的，如果我在SSO没有登录，而是直接在浏览器中敲入回调的地址，并带上伪造的用户信息，是不是业务系统也认为登录了呢？这是很可怕的。
总结单点登录（SSO）的所有流程都介绍完了，原理大家都清楚了。总结一下单点登录要做的事情：
单点登录（SSO系统）是保障各业务系统的用户资源的安全 。各个业务系统获得的信息是，这个用户能不能访问我的资源。单点登录，资源都在各个业务系统这边，不在SSO那一方。 用户在给SSO服务器提供了用户名密码后，作为业务系统并不知道这件事。 SSO随便给业务系统一个ST，那么业务系统是不能确定这个ST是用户伪造的，还是真的有效，所以要拿着这个ST去SSO服务器再问一下，这个用户给我的ST是否有效，是有效的我才能让这个用户访问。