大家好，今天给各位分享阅读这篇有关单点登录(SSO) 的文章就足够了。的一些知识，其中也会对进行解释，文章篇幅可能偏长，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在就马上开始吧！

非常不方便。于是，我就想，是否可以只登录一个系统，而不需要登录其他系统呢？这就是单点登录解决的问题。

单点登录的英文全称是Single Sign On，缩写是SSO。它的解释是：在多个应用系统中，只需要登录一次就可以访问其他相互信任的应用系统。

图像

如图所示，图中有4个系统，分别是Application1、Application2、Application3、SSO。 Application1、Application2、Application3没有登录模块，而SSO只有登录模块，没有其他业务模块。当Application1、Application2、Application3需要登录时，会跳转到SSO系统。 SSO系统完成登录，其他应用系统随之完成。已登录。这完全符合我们对单点登录(SSO) 的定义。

技术实现

在讲单点登录（SSO）的技术实现之前，我们先讲一下普通的登录认证机制。

图像

如上图所示，我们在浏览器（Browser）中访问一个应用程序。此应用程序需要登录。当我们填写用户名和密码后，我们就完成了登录认证。这时，我们在用户的会话中将登录状态标记为yes（已登录），并在浏览器（Browser）中写入cookie。该cookie是用户的唯一标识符。下次我们访问该应用程序时，该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中，同时记录在浏览器端（Browser）的sso中。 Cookie 写在a.com 下。那么如何才能让app1.a.com和app2.a.com登录呢？这里有两个问题：

Cookie 不能跨域。我们的cookie的域属性是sso.a.com，向app1.a.com和app2.a.com发送请求时不能使用该属性。 sso、app1 和app2 是不同的应用程序。他们的会话存在于自己的应用程序中并且不共享。

图像

那么我们如何解决这两个问题呢？关于第一个问题，sso登录后，可以将cookie域设置为top域，即。 a.com，这样所有子域系统都可以访问顶级域的cookie。我们设置cookie的时候只能设置顶级域和自己的域，不能设置其他域。例如：我们不能在自己的系统中为baidu.com域设置cookie。

cookie问题解决了，我们再来看看session问题。我们登录sso系统，然后再次访问app1。该cookie也被带到app1的服务器上。 app1的服务器如何找到这个cookie对应的Session呢？这里我们需要共享三个系统的Session，如图。共享Session的解决方案有很多，比如Spring-Session。这就解决了第二个问题。

实现了同域下的单点登录，但这并不是真正的单点登录。

不同域下的单点登录

同域下的单点登录巧妙利用了Cookie顶域的特性。如果是不同的域怎么办？ Cookie 不在不同域之间共享。我应该怎么办？

这里我们要讲的是CAS流程，它是单点登录的标准流程。

cas_flow_diagram

上图是CAS官网上的标准流程。具体流程如下：

当用户访问应用系统时，应用系统要求登录，但用户尚未登录。跳转到CAS服务器，也就是SSO登录系统。从现在起，图中的CAS Server将被称为SSO系统。没有登录SSO系统，弹出用户登录页面。用户填写用户名和密码，SSO系统进行身份验证后，将登录状态写入SSO会话，并将SSO域下的cookie写入浏览器。 SSO系统登录完成后，会生成一个ST（Service Ticket），然后跳转到app系统，并将ST作为参数传递给app系统。 App系统获取ST后，从后台向SSO发送请求，验证ST是否有效。验证通过后，应用系统将登录状态写入会话，并在应用域中设置cookie。至此，跨域单点登录就完成了。以后我们访问app系统的时候，app就会登录，接下来我们看一下访问app2系统的流程。

用户访问app2系统，但app2系统未登录，跳转至SSO。由于SSO已经登录，因此无需再次登录进行身份验证。 SSO生成ST，浏览器跳转到app2系统，并将ST作为参数传递给app2。 app2拿到ST，在后台访问SSO，验证ST是否有效。验证成功后，app2将登录状态写入session，并将cookie写入app2域下。这样app2系统就不需要走登录流程了，已经登录了。SSO、app和app2在不同的域，他们之间的会话不共享也没有问题。

有同学问我，登录SSO系统后，跳回原来的业务系统时，带了一个参数ST。业务系统还需要使用ST再次接入SSO进行验证。我感觉这一步有点多余。他想在通过SSO登录认证后，通过回调地址将用户信息返回到原业务系统。原业务系统直接设置登录状态。这样流程就简单了，登录就完成了。不是很好吗？

事实上，这个问题是非常严重的。如果我不登录SSO，而是直接在浏览器中输入回调地址，并带上虚假的用户信息，业务系统也会认为我已经登录了吗？这太可怕了。