目录
1、单点登录(SSO)是什么
单点登录（SSO，Single Sign On），是在企业内部多个应用系统（如考勤系统、财务系统、人事系统等）场景下，用户只需要登录一次，就可以访问多个应用系统。
同理用户只需注销一次，就可以从多个应用系统退出登录。
简单来说就是，一次登录，全部登录！一次注销，全部注销！！
2、单点登录的实现方式
单点登录的实现方案，一般就包含：Cookie、Session、Token
单点登录的本质就是在多个应用系统中共享登录状态。如果用户的登录状态是记录在 Session 中的，要实现共享登录状态，就要先共享 Session，比如可以将 Session 序列化到 Redis 中，让多个应用系统共享同一个 Redis，直接读取 Redis 来获取 Session。当然仅此是不够的，因为不同的应用系统有着不同的域名，尽管 Session 共享了，但是由于 Session ID 是往往保存在浏览器 Cookie 中的，因此存在作用域的限制，无法跨域名传递，也就是说当用户在 app1.com 中登录后，Session ID 仅在浏览器访问 app1.com 时才会自动在请求头中携带，而当浏览器访问 app2.com 时，Session ID 是不会被带过去的。实现单点登录的关键在于，如何让 Session ID（或 Token）在多个域中共享。
实现方式一：父域 Cookie
在将具体实现之前，我们先来聊一聊 Cookie 的作用域。
Cookie 的作用域由 domain 属性和 path 属性共同决定。domain 属性的有效值为当前域或其父域的域名/IP地址，在 Tomcat 中，domain 属性默认为当前域的域名/IP地址。path 属性的有效值是以“/”开头的路径，在 Tomcat 中，path 属性默认为当前 Web 应用的上下文路径。
如果将 Cookie 的 domain 属性设置为当前域的父域，那么就认为它是父域 Cookie。Cookie 有一个特点，即父域中的 Cookie 被子域所共享，换言之，子域会自动继承父域中的Cookie。
利用 Cookie 的这个特点，不难想到，将 Session ID（或 Token）保存到父域中不就行了。没错，我们只需要将 Cookie 的 domain 属性设置为父域的域名（主域名），同时将 Cookie 的 path 属性设置为根路径，这样所有的子域应用就都可以访问到这个 Cookie 了。不过这要求应用系统的域名需建立在一个共同的主域名之下，如 tieba.baidu.com 和 map.baidu.com，它们都建立在 baidu.com 这个主域名之下，那么它们就可以通过这种方式来实现单点登录。
总结：此种实现方式比较简单，但不支持跨主域名。
实现方式二：认证中心
我们可以部署一个认证中心，认证中心就是一个专门负责处理登录请求的独立的 Web 服务。
用户统一在认证中心进行登录，登录成功后，认证中心记录用户的登录状态，并将 Token 写入 Cookie。（注意这个 Cookie 是认证中心的，应用系统是访问不到的。）
应用系统检查当前请求有没有 Token，如果没有，说明用户在当前系统中尚未登录，那么就将页面跳转至认证中心。由于这个操作会将认证中心的 Cookie 自动带过去，因此，认证中心能够根据 Cookie 知道用户是否已经登录过了。如果认证中心发现用户尚未登录，则返回登录页面，等待用户登录，如果发现用户已经登录过了，就不会让用户再次登录了，而是会跳转回目标 URL ，并在跳转前生成一个 Token，拼接在目标 URL 的后面，回传给目标应用系统。
应用系统拿到 Token 之后，还需要向认证中心确认下 Token 的合法性，防止用户伪造。确认无误后，应用系统记录用户的登录状态，并将 Token 写入 Cookie，然后给本次访问放行。（注意这个 Cookie 是当前应用系统的，其他应用系统是访问不到的。）当用户再次访问当前应用系统时，就会自动带上这个 Token，应用系统验证 Token 发现用户已登录，于是就不会有认证中心什么事了。
这里顺便介绍两款认证中心的开源实现：
-
Apereo CAS 是一个企业级单点登录系统，其中 CAS 的意思是”Central Authentication Service“。它最初是耶鲁大学实验室的项目，后来转让给了 JASIG 组织，项目更名为 JASIG CAS，后来该组织并入了Apereo 基金会，项目也随之更名为 Apereo CAS。
-
XXL-SSO 是一个简易的单点登录系统，由大众点评工程师许雪里个人开发，代码比较简单，没有做安全控制，因而不推荐直接应用在项目中，这里列出来仅供参考。
总结：此种实现方式相对复杂，支持跨域，扩展性好，是单点登录的标准做法。
实现方式三：LocalStorage 跨域
前面，我们说实现单点登录的关键在于，如何让 Session ID（或 Token）在多个域中共享。
父域 Cookie 确实是一种不错的解决方案，但是不支持跨域。那么有没有什么奇淫技巧能够让 Cookie 跨域传递呢？
很遗憾，浏览器对 Cookie 的跨域限制越来越严格。Chrome 浏览器还给 Cookie 新增了一个 SameSite 属性，此举几乎禁止了一切跨域请求的 Cookie 传递（超链接除外），并且只有当使用 HTTPs 协议时，才有可能被允许在 AJAX 跨域请求中接受服务器传来的 Cookie。
不过，在前后端分离的情况下，完全可以不使用 Cookie，我们可以选择将 Session ID （或 Token ）保存到浏览器的 LocalStorage 中，让前端在每次向后端发送请求时，主动将 LocalStorage 的数据传递给服务端。这些都是由前端来控制的，后端需要做的仅仅是在用户登录成功后，将 Session ID （或 Token ）放在响应体中传递给前端。
在这样的场景下，单点登录完全可以在前端实现。前端拿到 Session ID （或 Token ）后，除了将它写入自己的 LocalStorage 中之外，还可以通过特殊手段将它写入多个其他域下的 LocalStorage 中。
前端通过 iframe+postMessage() 方式，将同一份 Token 写入到了多个域下的 LocalStorage 中，前端每次在向后端发送请求之前，都会主动从 LocalStorage 中读取 Token 并在请求中携带，这样就实现了同一份 Token 被多个域所共享。
总结：此种实现方式完全由前端控制，几乎不需要后端参与，同样支持跨域。
3、单点登录（SSO）如何处理跨域身份验证
1）跨域资源共享（CORS）
CORS是一种浏览器机制，允许Web应用程序在不同的域之间共享资源。通过在认证中心和应用程序之间设置CORS，可以实现跨域身份验证。
2）JSON Web Token（JWT）
JWT是一种基于JSON的令牌，可以在不同的域之间安全地传输数据。通过使用JWT，在认证中心和应用程序之间传递用户身份验证和授权信息，实现跨域身份验证。
3）代理服务器
您可以在认证中心和应用程序之间设置代理服务器，将跨域请求重定向到认证中心，并返回身份验证和授权信息，以便应用程序进行身份验证。
4、单点登录的实现原理
单点登录的实现原理说明如下：
1. 用户首次访问系统A时，需要进行登录。
2. 系统A带着用户登录信息重定向给认证系统。
3. 认证系统验证用户登录信息。
4. 验证通过后，返回一个token（Tip：token类似一种内部的通行证，包含了用户身份信息、登录状态和过期时间，在各个系统间共享。）
5. 认证系统带着token重定向给系统A，得知用户是已登录状态。
6. 系统A向用户返回请求的资源。
7. 用户访问系统B时，需要进行登录。
8. 系统B通过共享的token，得知用户是已登录状态。
9. 系统B向用户返回请求的资源。
Token是有时效性的，如果用户长时间没有操作，token将会过期。
Token过期后用户再次访问系统A、系统B时，登录状态已失效，需要重新登录。
对于注销场景，与上述流程类似。
用户主动从系统A注销时，系统A调用认证系统，清除token。
此时用户再访问系统A、系统B时，通过共享的token得知用户是已注销状态，需要重新登录。
*单点登录原理可参考：www.cnblogs.com/ywlaker/p/6…
#总结
单点登录通过在用户和系统之间引入认证系统。以往用户需要分别对接各个应用系统进行登录/注销，现在用户只需要单独对接认证系统进行登录/注销。
登录状态在各个应用系统间共享，体现了把简单留给用户，把复杂留给后台系统的设计理念。极大节省了用户时间，提高了用户体验。
5、单点登录（SSO）退出
目前我们已经完成了单点登录，在同一套认证中心的管理下，多个产品可以共享登录态。在一个产品中退出了登录，怎么让其他的产品也都退出登录？
可以在每一个产品在向认证中心验证 ticket(token) 时，其实可以顺带将自己的退出登录 api 发送到认证中心。
当某个产品 c.com 退出登录时：
- 清空
c.com中的登录态Cookie。 - 请求认证中心
sso.com中的退出api。 - 认证中心遍历下发过
ticket(token)的所有产品，并调用对应的退出api，完成退出。
6、单点登录的优点与缺点
优点
1）提高用户的效率。
用户不再被多次登录困扰，也不需要记住多个 ID 和密码。另外，用户忘记密码并求助于支持人员的情况也会减少。
2）提高开发人员的效率。
SSO 为开发人员提供了一个通用的身份验证框架。实际上，如果 SSO 机制是独立的，那么开发人员就完全不需要为身份验证操心。他们可以假设，只要对应用程序的请求附带一个用户名，身份验证就已经完成了。
3）简化管理。
如果应用程序加入了单点登录协议，管理用户账号的负担就会减轻。简化的程度取决于应用程序，因为 SSO 只处理身份验证。所以，应用程序可能仍然需要设置用户的属性（比如访问特权）。
缺点
1）不利于重构
因为涉及到的系统很多，要重构必须要兼容所有的系统，可能很耗时。
2） 无人看守桌面
因为只需要登录一次，所有的授权的应用系统都可以访问，可能导致一些很重要的信息泄露。
7、单点登录如何提高用户体验
1）简化登录流程
SSO可以让用户在一个认证中心登录后，无需再次输入用户名和密码，即可访问其他应用程序，减少了重复登录的麻烦，简化了登录流程。
2）统一用户标识
SSO可以使用统一的用户标识，例如电子邮件地址或员工号码等，减少了用户需要记住多个不同的用户名和密码的烦恼。
3）提高访问速度
由于用户只需要登录一次，就可以访问多个应用程序，因此可以提高访问速度，减少等待时间。
4）提高可用性
SSO可以让用户在不同的设备上访问同一应用程序，例如在手机、平板电脑或桌面电脑上，提高了应用程序的可用性和灵活性。
5）提高安全性
由于SSO使用统一的身份验证机制，可以减少用户使用弱密码或重复密码的可能性，提高了安全性，从而提高了用户的信任感和满意度。
8、单点登录如何提高安全性
1）强制密码策略
通过强制密码策略，例如长度、复杂性和更改频率，可以增加密码的安全性，减少被猜测或破解的可能性。
2）多因素身份验证
在登录过程中使用多种身份验证方式，例如短信验证码、智能卡、生物识别技术等，可以提高安全性。
3）会话管理
会话管理可以限制用户的访问权限和时间，确保用户只能访问他们被授权的资源，并在一段时间后自动注销用户的会话。
4）安全协议
使用安全协议，例如SSL或TLS，可以保证通信过程中数据的加密和完整性。
5）监控和审计
实时监控单点登录系统的访问日志和审计日志，及时发现异常行为，保障系统的安全性。
9、单点登录(SSO)与传统身份验证方法有何区别
1）登录次数
传统身份验证方法需要用户在每个应用程序中都输入用户名和密码进行登录，而SSO只需要用户登录一次就可以访问多个应用程序。
2）用户体验
传统身份验证方法需要用户在不同的应用程序之间进行切换和登录，造成了不必要的麻烦和时间浪费，而SSO可以简化登录流程，提高用户体验。
3）安全性
传统身份验证方法中，用户需要记住多个不同的用户名和密码，容易造成弱密码或重复密码的情况，而SSO可以使用强密码策略和多因素身份验证等措施提高安全性。
4）统一管理
传统身份验证方法中，每个应用程序都有自己的用户数据库和身份验证机制，难以统一管理，而SSO可以使用统一的认证中心进行身份验证和用户管理。
5）可扩展性
传统身份验证方法难以适应新的应用程序和设备，而SSO可以通过添加新的应用程序和身份验证机制来扩展功能。
参考链接
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
