你真的了解单点登录（SSO）吗？单点登录实现方式

在程序开发中，特别是网站类开发，会接触到单点登录(SSO)，什么是单点登录？单点登录(SSO)有什么用？下面就来详细介绍一下。

1 单点登录

1.1 什么是单点登录

单点登录的英文名叫做：Single Sign On（简称SSO），它是一种身份验证解决方案，可让用户通过一次性用户身份验证登录多个应用程序和网站。鉴于当今的用户经常直接从其浏览器访问应用程序，因此组织正在优先考虑改善安全性和用户体验的访问管理策略。SSO 兼具这两方面的优点，因为一旦验证身份，用户就可以访问所有受密码保护的资源，而无需重复登录。

在以前的时候，一般我们的系统都是单系统，也就是说所有的功能都在同一个系统上。

后来，为了合理利用资源和降低耦合性，于是把单系统拆分成多个子系统。

比如阿里系的淘宝和天猫，很明显地我们可以知道这是两个系统，但是你在使用的时候，登录了天猫，淘宝也会自动登录。

简单来说，单点登录就是在多个系统中，用户只需一次登录，各个系统即可感知该用户已经登录。

1.2 单系统的登录方式

HTTP是无状态的协议

众所周知，HTTP是无状态的协议，这意味着服务器无法确认用户的信息。于是乎，W3C就提出了：给每一个用户都发一个通行证，无论谁访问的时候都需要携带通行证，这样服务器就可以从通行证上确认用户的信息。这个通行证就是Cookie。

如果说Cookie是检查用户身上的”通行证“来确认用户的身份，那么Session就是通过检查服务器上的”客户明细表“来确认用户的身份的。Session相当于在服务器中建立了一份“客户明细表”。

HTTP协议是无状态的，Session不能依据HTTP连接来判断是否为同一个用户。于是乎：服务器向用户浏览器发送了一个名为JESSIONID的Cookie，它其实就是 sessionID。其实Session是依据Cookie来识别是否是同一个用户。

cookie数据存放在客户的浏览器（客户端）上，session数据放在服务器上，但是服务端的session的实现对客户端的cookie有依赖关系的，这个关系通过sessionID来维护。

所以，一般我们单系统实现登录会这样做：

用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session；
请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器；
浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名；
当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息;
- 如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息；
- 如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。
此时，当我们在该网站的不同的网页中左右横跳的时候，通过跟随request中的cookie中的 sessionID ，使用相同的session。
当过了一段时间后，，服务器中对应的session的生命周期过去，session中的内容写入数据库，该session被清除。
此时再访问页面，会使用cookie重新登录，服务器重新创建session，重复上述过程。

根据以上流程可知，SessionID 是连接 Cookie 和 Session 的一道桥梁，大部分系统也是根据此原理来验证用户登录状态。

Cookie的作用是什么?和Session有什么区别？

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。

Cookie 一般用来保存用户信息，比如：

我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；
一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候 我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；
登录一次网站后访问网站其他页面不需要重新登录。

Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。

Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果使用 Cookie，那么最好不要将一些敏感信息不要写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。

2 多系统登录方式

2.1 同域名下的单点登录

一个企业一般情况下只有一个域名，通过二级域名区分不同的系统。比如我们有个域名 a.com，同时有两个业务系统service1.a.com和service2.a.com。我们要做单点登录（SSO），需要一个登录系统 sso.a.com。用户只要在sso.a.com登录，那么service1.a.com和service2.a.com就也登录了。

用户在sso.a.com中登录之后，其实是在sso.a.com的服务端session中记录了登录状态，同时在浏览器端（Browser）的sso.a.com下写入了Cookie。那么我们怎么才能让service1.a.com和service2.a.com登录呢？这里有两个问题：

Cookie跨域：Cookie是不能跨域的，Cookie的domain属性是sso.a.com，在给service1.a.com和service2.a.com发送请求是带不上的。
Session不共享：sso、service1和service2是不同的应用，它们的session存在自己的应用内，是不共享的。

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

Cookie的问题解决了，我们再来看看session的问题。我们在SSO系统登录了，这时再访问service1，Cookie也带到了service1的服务端，service1的服务端怎么找到这个Cookie对应的Session呢？这里就要把3个系统的Session共享。共享Session的解决方案有很多，例如：

- 把Session数据放在Redis中（使用Redis模拟Session）
Spring-Session。这样第2个问题也解决了。

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

2.2 不同域下的单点登录

同域下的单点登录是巧用了Cookie顶域的特性。如果是不同域呢？不同域之间Cookie是不共享的，怎么办？ 这时候就需要 CAS（Central Authentication Service）了。CAS是由耶鲁大学实验室2002年出的一个开源的统一认证服务。旨在为 Web 应用系统提供一种可靠的单点登录解决方法。

现在将登录单独抽取成SSO系统，并且有两个应用 app1和app2以及用户 A，分别是：

app1：www.app1.com；
app2：www.app2.com；
认证中心SSO：www.sso.com。

用户A访问app1流程（此时用户还未与认证中心建立全局会话）

用户想要访问app1（www.app1.com），app1（www.app1.com）发现用户并没有登录，于是重定向到sso认证中心，并将自己的地址作为参数。请求的地址如下：
```
https://www.sso.com?service=www.app1.com
```
SSO认证中心发现用户未登录，将用户引导至登录页面，用户进行输入用户名和密码进行登录，用户与认证中心建立全局会话（根据用户信息生成一个token，写到Cookie中，保存在浏览器上）。
认证中心重定向回app1（www.app1.com），并把Token携带过去给app1，重定向的地址如下：
```
https://www.app1.com?token=xxxxxxx
```
接着，系统A去sso认证中心验证这个Token是否正确，如果正确，则系统A和用户建立局部会话（创建Session）。到此，系统A和用户已经是登录状态了。

用户A登录app2流程（此时用户A已经与认证中心建立全局会话）

用户A 想要访问app2（www.app2.com），app2（www.app2.com）发现用户并没有登录，于是重定向到SSO认证中心，并将自己的地址作为参数。请求的地址如下：
```
https://www.sso.com?service=www.app2.com
```
因为之前用户A与认证中心www.sso.com已经建立了全局会话（当时已经把Cookie保存到浏览器上了），所以这次系统B重定向到认证中心www.sso.com是可以带上Cookie的（重要重要重要）。
认证中心根据带过来的Cookie发现已经与用户建立了全局会话了，认证中心重定向回app2（www.app2.com），并把Token携带过去给app2，重定向的地址如下：
```
https://www.order.com?token=xxxxxxx
```
接着，系统B去SSO认证中心验证这个Token是否正确，如果正确，则app2和用户A建立局部会话（创建Session）。到此，app2和用户已经是登录状态了。

疑问解答：用户A登录SSO系统后，携带Token重定向会app，app还要拿Token再次访问SSO进行验证，大家可能会觉得这个步骤有点多余。

可能大家会想，用户A认证通过SSO后，通过回调地址将Token返回给原业务系统，原业务系统直接设置登录状态，这样流程简单，也完成了登录，那为什么还要还要拿Token再次访问SSO进行验证呢？

其实这样问题时很严重的，如果用户在SSO没有登录，而是直接在浏览器中敲入回调的地址，并带上伪造的用户信息，是不是业务系统也认为登录了呢？这是很可怕的。

其实SSO认证中心就类似一个中转站。

参考文章：https://blog.csdn.net/cnpinpai/article/details/90669587
参考文章：https://developer.aliyun.com/article/636281