背景:

在企业发展初期的时候,企业公司只有一个server,慢慢的server开始增多,但是每个server都要进行注册登录,退出的时候又要一个一个退出,用户体验很不好,比如上豆瓣 要登录豆瓣FM、豆瓣读书、豆瓣电影、豆瓣日记......,每上一个都要注册登录是很麻烦的,所以要简化这些东西,实现一次注册,一次登录与一次退出,SSO就诞生了.

概述:

单点登录(Single Sign On),简称SSO,是目前比较流行的企业业务整合的解决方案之一,SSO系统当中,用户只要登录一次就可以访问相互信任的应用系统,常用的用户认证有Auth,CAS,应用场景为:

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

技术实现:

普通的登录认证机制:

如上图,我们在浏览器中访问一个应用,这个应用需要登录,我们填完用户名和密码之后完成登录认证,在这个时候我们在这个用户的session中标记登录状态为yes,同时在浏览器中写入Cookie,这个cookie是用户的唯一标识,下次我们在访问该应用的时候请求会带上这个cookie(session_Id),服务器端会根据这个cookie找到对应的session来判断该用户是否登录,如果不做特殊配置,这个cookie的名字就是jsessionid,值在server是唯一的.

同域下的单点登录:

一个企业一般情况下只有一个域名,通过二级域名区分不同的系统,比如我们有个域名叫做：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.a.com下写入了Cookie。那么我们怎么才能让app1.a.com和app2.a.com登录呢？这里有两个问题：

1.Cookie是不能跨域的，我们Cookie的domain属性是sso.a.com，在给app1.a.com和app2.a.com发送请求是带不上的。

2.sso、app1和app2是不同的应用，它们的session存在自己的应用内，是不共享的。

对于这两个问题解决方案如下:

1.sso登录之后,将cookie设置到顶域当中,即a.com,这样所有子域系统都可以访问到顶域的cookie,我们在设置Cookie时，只能设置顶域和自己的域，不能设置其他的域。比如：我们不能在自己的系统中给baidu.com的域设置Cookie。

2.通过session共享机制,就可以解决该问题

通过这些,同域下的单点登录就实现了,单这还不是真正的单点登录.

不同域下的单点登录:

同一域下面的单点登录是巧用了cookie顶域特性,但是对于不同域来说就要使用CAS/Auth来解决了,例如CAS流程:

1.用户访问app系统，app系统是需要登录的，但用户现在没有登录。

2.跳转到CAS server，即SSO登录系统， SSO系统也没有登录，弹出用户登录页。

3.用户填写用户名、密码，SSO系统进行认证后，将登录状态写入SSO的session，浏览器（Browser）中写入SSO域下的Cookie。

4.SSO系统登录完成后会生成一个ST（Service Ticket,浏览器端），然后跳转到app系统，同时将ST作为参数传递给app系统。

5.app系统拿到ST后，从后台向SSO发送请求，验证ST是否有效。

6.验证通过后，app系统将登录状态写入session并设置app域下的Cookie。

至此，跨域单点登录就完成了。以后我们再访问app系统时，app就是登录的。接下来，我们再看看访问app2系统时的流程。

1.用户访问app2系统，app2系统没有登录，跳转到SSO。

2.由于SSO已经登录了，不需要重新登录认证。

3.SSO生成ST，浏览器跳转到app2系统，并将ST作为参数传递给app2。

4.app2拿到ST，后台访问SSO，验证ST是否有效。

5.验证成功后，app2将登录状态写入session，并在app2域下写入Cookie。

这样，app2系统不需要走登录流程，就已经是登录了。SSO，app和app2在不同的域，它们之间的session不共享也是没问题的。

注意:

SSO系统登录后，跳回原业务系统时，带了个参数ST，业务系统还要拿ST再次访问SSO进行验证，如果通过回调地址将用户信息返回给原业务系统，原业务系统直接设置登录状态，这样会产生很严重的问题，如果我在SSO没有登录，而是直接在浏览器中敲入回调的地址，并带上伪造的用户信息，业务系统也认为登录了,这是很可怕的

总结:

1.单点登录保证了各业务用户资源的安全

2.各个业务系统判断该用户能不能访问我的资源

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

参考链接:

https://yq.aliyun.com/articles/636281?spm=a2c4e.11153940.0.0.23aa6088Lu1GcS&p=1#comments