单点登录(SSO)

最新推荐文章于 2026-04-22 05:12:37 发布

转载最新推荐文章于 2026-04-22 05:12:37 发布 · 438 阅读

标签

#java #session #cookie #sso #单点登录

随笔专栏收录该内容

14 篇文章

订阅专栏

1.背景

在互联网发展远不如今天迅速的初期，每个企业使用的系统就一两个。每个系统都有自己的登录模块，运营人员每天使用自己的账号登录，很方便。但随着企业的发展，每天要用到的系统越来越多，登陆起来也变得不是很方便。有需要便有技术，于是想到可不可以在一个系统登录，然后其它系统就不用登陆了，单点登录由此产生了。

单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

如图所示，图中有四个系统，Application1，Application2，Application3和SSO。Application1，Application2，Application3只有业务模块，没有登录模块，而SSO只是登录模块，没有业务模块。当用户需要登录时，不管访问那个系统，都会跳转到SSO系统登录，用户在SSO系统完成登录，其他系统也就登录成功了。这就是单点登录。

2.普通登陆的认证机制

在学习单点登录之前，先来看一看普通登录的实现机制

当你在浏览器访问一个应用时，该应用需要登录，你在其登陆页面输入用户名密码进行登录。完成登录验证后，请求发送给服务器。服务器将该用户登录状态标记为yes，保存在Session中，并返回给客户端Cookie，Cookie是该客户端的唯一标识。下次客户端访问时，请求中带上Cookie，浏览器会根据Cookie找到对应的Session，通过Session来判断该用户是否登录。

3.同域下单点登录

一般一个企业只有一个域名，通过二级域名区分不同的系统。比如有一个企业的域名为yc.com，他们有两个业务系统域名分别为app1.yc.com和app2.yc.com，现在要实现单点登录。需要一个域名为sso.yc.com的登录系统。

我们要实现在sso.yc.com登录，则app1.yc.com和app2.yc.com也登陆。通过上边的认证机制我们知道，当sso.yc.com登录后，会在sso.yc.com系统的服务器的Session中记录了登录状态，同时也会写入sso.yc.com的客户端的Cookie中。那么如何让app1.yc.com和app2.yc.com实现登录呢？这里有两个问题：

Cookie是不能跨域的，sso.yc.com的domain属性是sso.yc.com，app1.yc.com和app2.yc.com发送请求的时候是带不上的。
sso,app1,app2是不同的应用，他们的Session存在自己的内存中，不是共享的。

针对以上两个问题。第一个问题，将Cookie的域设置为顶域yc.com。这样所有子域都能访问顶域的Cookie了。（我们在设置Cookie的时候只能设置为自己的域或者顶域）。

Cookie的问题解决了，接下来我们来解决Session。在sso登录后，再访问app1，服务器返回的Cookie也被带到了app1。为了使app1的服务器能根据app1发送过来的Cookie找到对应的Session，我们应该将三个应用的Session共享。共享的方法有很多，比如Spring-Session，这个可以参考我的另一篇博客。

4.不同域下的单点登录

同域下的单点登录巧用了Cookie顶域的属性，但不同域下的该如何解决。不同域间的Cookie是不共享的，又该如何？

这里我们就要说一说CAS流程了，这个流程是单点登录的标准流程。

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

用户访问app1，app1系统需要登录，但目前没有登录。
会跳转到CAS Server，就是我们刚刚说的登陆系统SSO（下文统一将CAS Server称为SSO）。由于SSO也没有登录，因此弹出登录界面。
用户填写用户名和密码，SSO系统经过验证后，在SSO服务器端的Session中写下登录状态，客户端写入SSO域下的Cookie中。
SSO系统登录完成后会生成一个ST(Service Ticket)，然后跳转到app1系统，并将ST作为参数传递过去。
app1系统拿到ST后，向SSO系统发送验证，判断ST是否有效。（该步骤的验证很重要：如果SSO系统没有登录，而是直接伪造登录信息，那app系统也判断该用户已登录，就绕过了SSO登陆系统成功登录上了app1）
验证成功后，app1系统将登录状态写入Session并设置app1域下的Cookie。

至此，单点登陆系统就完成了，当我们在此访问app系统时，他就是登录状态。下面我们接着访问app2系统时，具体流程如下：

用户访问app2，app2需要登录，跳转到SSO系统。
当前SSO系统已经登录，不需要重新登录认证。
SSO系统生成ST，跳转到app2，将ST作为参数传递过去。
app2系统拿到ST后，向SSO发送验证，判断ST是否有效。
验证成功后，app2系统将登陆状态写入Session，并在app2下写入Cookie。

这样，app2不需要走登录流程就已经是登录状态。SSO，app1，app2在不同的域，它们之间的Session也没有共享，完全没问题。

5.总结

单点登录（SSO系统）是保障各业务系统的用户资源的安全。
各个业务系统获得的信息是，这个用户能不能访问我的资源。
单点登录，资源都在各个业务系统这边，不在SSO那一方。用户在给SSO服务器提供了用户名密码后，作为业务系统并不知道这件事。 SSO随便给业务系统一个ST，那么业务系统是不能确定这个ST是用户伪造的，还是真的有效，所以要拿着这个ST去SSO服务器再问一下，这个用户给我的ST是否有效，是有效的我才能让这个用户访问。