单点登录简介
SSO定义和概念
单点登录（Single Sign-On，简称SSO） 是一种身份验证和授权机制，旨在让用户只需一次登录，就能够访问多个相关但独立的系统或应用。在传统的身份验证模型中，用户需要为每个系统提供独立的凭证（通常是用户名和密码），这不仅繁琐而且容易导致安全隐患。
SSO解决了这一问题，通过一次登录，用户获取了对多个系统的访问权限，而无需在每个系统中重新输入凭证。这样的集中式身份验证模型极大地提升了用户体验，减轻了用户的记忆负担，同时也有助于提高整体系统的安全性。
SSO的概念基于用户身份的共享，通过在用户登录时颁发令牌（Token）的方式，实现用户在不同系统之间的无缝切换。这个令牌包含有关用户身份和权限的信息，服务提供者可以通过验证这个令牌来确认用户的身份，而无需用户提供额外的凭证。
总的来说，SSO的核心理念是通过一次登录，实现对多个系统的授权，从而提高用户体验、减少密码管理的负担，并增强整体系统的安全性。
单点登录的好处
单点登录（SSO）作为一种集中式身份验证机制，带来了多方面的优势，从用户体验、安全性到管理维护都得到了显著的提升。
1. 用户体验的提升: 单点登录（SSO）通过一次登录，用户即可访问多个相关系统，无需反复输入凭证，极大提高了用户体验。这种便捷性能够吸引更多用户使用系统和服务，提升用户满意度。
2. 减轻用户记忆负担: 通过集中管理身份验证，用户只需记住一个账户和密码，减轻了用户的记忆负担。这不仅提高了用户对系统的黏性，也降低了因多账户密码而带来的混淆和忘记密码的问题。
3. 安全性的增强: SSO系统可以集中实施更强大的身份验证和授权机制，如多因素认证。这有助于提高整个系统的安全性，降低密码泄露的风险，保护用户的个人信息和数据安全。
4. 简化管理和维护: 对于企业和组织来说，通过SSO，用户账户和权限的管理变得更加简便。系统管理员能够更轻松地进行用户管理，降低了管理和维护的成本，提高了工作效率。
5. 降低密码管理的复杂性: 用户不再需要在不同应用中设置和更新多个独立的密码。这简化了密码管理的复杂性，减少了用户忘记密码的情况，提高了整体的账户安全性。
6. 提高生产力: 用户在日常工作中不再受制于频繁的登录流程，能够更快速、高效地访问需要的应用和资源，从而提高了工作效率和生产力。SSO有助于提升工作流畅性，减少了不必要的操作步骤。
7. 促进统一标识管理: SSO推动了企业或组织内部对用户标识的集中管理。通过统一标识管理，可以更好地掌控用户权限，降低了滥用和误用的风险。
8. 快速应用部署和集成: 引入SSO机制可以加速新应用的部署，并简化已有应用的集成过程。这促进了系统架构的灵活性和敏捷性。
综合而言，单点登录的多重优势使其成为现代应用和企业系统中不可或缺的身份验证方式，为用户和企业带来了更好的体验和管理效率。
身边的案例
在身边，淘宝和天猫是两个典型的电商平台，它们采用了单点登录（SSO）机制，让用户能够方便快捷地在这两个平台间切换而无需重新登录。用户首次登录淘宝，完成登录后，可以在不再输入账号和密码的情况下访问天猫。这种SSO机制使用户在淘宝和天猫之间实现无缝切换，提升了用户体验。
流程说明：
- 首次登录： 用户首次访问淘宝网站。在登录页面，用户输入阿里巴巴的统一账户（例如阿里巴巴账号和密码）。
- SSO认证： 阿里巴巴的SSO系统对用户进行身份验证，验证通过后生成一个令牌（Token）。
- 令牌颁发： 身份验证成功后，SSO系统颁发一个令牌给用户。
- 令牌使用： 用户使用该令牌访问淘宝网站。这个令牌包含有关用户身份的信息。
- 无需重新登录访问天猫： 用户在淘宝登录后，无需重新输入账号和密码，即可直接访问天猫网站。令牌的有效性使用户能够在淘宝和天猫之间实现无缝切换。
单点登录的两种实现方式
基于Cookie实现单点登录
Cookie-Based SSO是指使用Cookie来实现单点登录功能的一种方式。其原理是，在用户第一次登录系统时，系统会为用户颁发一个令牌（Token）。这个令牌包含了用户身份信息和过期时间等元数据，并在服务器端保存副本。然后，系统将这个令牌放入响应的Cookie中返回给客户端浏览器，并在后续的每个请求中都携带这个Cookie。当用户访问其他应用系统时，这些系统会验证Cookie中的令牌信息，如果令牌有效，则允许用户访问系统资源。
优点
- 实现简单：Cookie-Based SSO实现起来比较简单，不需要大量的代码。仅需要在用户登录时颁发令牌，并在每个请求中验证Cookie即可。
- 可扩展性好：可以很容易地添加新的应用系统，只需要验证Cookie中的令牌即可。
缺点
- 安全性低：Cookie-Based SSO是基于Cookie实现的，Cookie可能会被盗用或者伪造。如果攻击者获取了有效的Cookie，则可以冒充用户身份，并访问被授权的系统资源。
- 用户体验差：用户第一次登录时需要输入用户名和密码，并为每个系统都颁发一个Cookie。这样会增加用户的操作量，并且在使用多个浏览器或清理Cookie时可能会造成登录状态失效的问题。
- 难以处理跨域问题：Cookie-Based SSO只适用于同一域名下的应用程序，对于不同域名之间的系统无法实现单点登录。
基于token实现单点登录
Token-Based SSO是指使用Token来实现单点登录功能的一种方式。其原理是，用户首先在认证服务器上进行身份验证，如果验证成功，则认证服务器会颁发一个Token。然后，这个Token会被发送到客户端浏览器，并通过HTTP请求携带在请求头中或者以参数的形式传递给其他应用系统。当用户访问其他应用系统时，这些系统会向认证服务器验证Token，如果Token有效，则允许用户访问系统资源。
优点
- 安全性高：Token-Based SSO使用Token来实现用户身份认证，Token本身是无法被伪造的，并且可以通过加密和签名等手段进一步加强安全性，可以有效防止Cookie劫持和伪造攻击。
- 用户体验好：用户只需要进行一次身份验证，并获得一个Token即可访问所有被授权的系统资源，不需要多次输入用户名和密码。同时，用户可以在任何时间清除应用系统保存的Token，以保护自身安全。
- 易于处理跨域问题：Token-Based SSO不依赖Cookie，因此可以很容易地处理跨域问题。
缺点
- 实现复杂：Token-Based SSO需要在认证服务器上实现用户身份验证、令牌颁发和Token验证等逻辑。这些逻辑可能比较复杂，需要一定的技术能力。
- 维护成本高：认证服务器需要长期维护和管理，才能保证系统的正常运行。另外，如果有多个应用系统需要接入SSO，还需要在每个系统中添加相应的Token验证逻辑，增加了维护成本。
单点登录原理
相比于单系统登录，SSO需要一个独立的认证中心，只有认证中心能接受用户的用户名密码等安全信息，其他系统不提供登录入口，只接受认证中心的间接授权。间接授权通过令牌实现，SSO认证中心验证用户的用户名密码没问题，创建授权令牌，在接下来的跳转过程中，授权令牌作为参数发送给各个子系统，子系统拿到令牌，即得到了授权，可以借此创建局部会话，局部会话登录方式与单系统的登录方式相同。这个过程，也就是单点登录的原理，用下图说明。
下面对上图简要描述：
-
用户初次访问或未携带 Token：
- 应用1检测到用户初次访问或未携带 Token。
- 应用1发现缺少 Token。
- 应用1返回登录地址给浏览器，并触发浏览器跳转到该登录地址。
-
用户登录认证：
- 用户向 SSO 认证中心进行登录。
- SSO 认证中心验证用户信息成功后，生成 Token 和过期时间。
- 将 Token 和过期时间返回给浏览器。
-
Token 存储与传递：
- 前端将 Token 存储在浏览器的 Cookie 中，域名设置为 test.com。
-
再次访问应用1时：
- 用户再次请求应用1，并携带 Token 在请求头中。
-
本地缓存中获取用户信息：
- 应用1从本地缓存中通过 Token 获取用户信息。
-
获取不到用户信息时，向 SSO 获取：
- 若本地缓存中未找到用户信息，应用1通过 Token 向 SSO 认证中心获取用户信息。
-
SSO 验证 Token：
- SSO 认证中心验证 Token 成功后，将用户信息和 Token 过期时间返回给应用1。
-
本地缓存用户信息：
- 应用1将用户信息、Token 和过期时间缓存在本地。
-
进一步鉴权和资源返回：
- 应用1进行进一步鉴权，验证成功后返回受保护资源。
-
使用相同 Token 再次获取资源：
- 用户下一次使用相同 Token 请求资源。
-
本地缓存中获取用户信息再次鉴权：
- 应用1通过 Token 从本地获取用户信息。
-
鉴权成功后返回资源：
- 获取到用户信息后再次进行鉴权，成功后返回受保护资源。
-
用户向虚拟电厂平台发起请求：
- 用户从 Cookie 中获取 Token 并携带访问虚拟电厂平台。
-
虚拟电厂平台获取用户信息：
- 虚拟电厂平台通过 Token 从本地缓存中获取用户信息。
-
获取不到用户信息时，向 SSO 获取：
- 若本地缓存中未找到用户信息，虚拟电厂平台通过 Token 向 SSO 认证中心获取用户信息和 Token 过期时间。
-
SSO 验证 Token：
- SSO 认证中心验证 Token 成功后，将用户信息和 Token 过期时间返回给虚拟电厂平台。
-
虚拟电厂平台本地缓存用户信息：
- 虚拟电厂平台将用户信息、Token 和过期时间缓存在本地。
-
虚拟电厂平台进一步鉴权和资源返回：
- 虚拟电厂平台进行进一步鉴权，验证成功后返回受保护资源。
-
用户登出：
- 用户向 SSO 认证中心进行登出。
-
Token 销毁和消息队列通知：
- SSO 认证中心对 Token 进行验证，验证成功后销毁 Token。
- SSO 认证中心通过消息队列向各个子系统发送通知，销毁局部 Token。
前端需要做的逻辑
- 创建单独的登录页面：
- 前端需要设计并创建一个单独的登录页面，用于用户进行身份验证。这个页面可以由SSO认证中心提供接口。
- 跳转到登录页面：
- 当用户访问各个系统时返回需要登录提示时，前端需要触发浏览器跳转到登录页面。可以通过重定向或打开新的登录窗口的方式实现。
- 处理登录成功后的 Token：
- 在登录页面完成用户身份验证后，前端需要将从服务器获取的 Token 存储在浏览器的 Cookie 中，同时设置域名为 test.com。
- 在请求中携带 Token：
- 在向各个系统发起请求时，前端需要从浏览器的 Cookie 中获取 Token，并将 Token 放置在请求头中，以便进行身份验证。
- 处理各系统的登出操作：
- 前端需要在各个系统中实现登出功能。当用户点击登出按钮时，前端应该向 SSO 认证中心发起登出请求，实现单点登出。
- 处理各系统的更新 Token 操作：
- 如果各个系统需要更新 Token，前端应该向 SSO 认证中心发起更新 Token 的请求，确保用户的身份信息保持最新。
- 与SSO进行通信：
- 前端需要处理与 SSO 认证中心的通信。这包括处理登录请求、登出请求以及更新 Token 的请求。使用适当的前端框架或库，例如 Axios 或 Fetch API，可以更方便地进行这些操作。
系统间交互
SSO通过kafka和子系统进行信息同步
子系统通过订阅对应的topic来和SSO进行信息同步。例如：当用户退出时，SSO会向对应的topic发送退出的token。子系统在收到消息后，需要清除本地缓存的token。
KAFKA_SERVERS:127.0.0.1:9092
新增用户信息
topic
sso_add_user_info
msg
{
"userId": 1,
"userName": "admin",
"userPhone": "14232323236",
"userEmail": "admin@test.com",
"alias": "系统管理员",
"avatar": "xxxxxxx",
"token": null
}
修改用户信息
topic
sso_update_user_info
msg
{
"userId": 1,
"userName": "admin",
"userPhone": "14232323236",
"userEmail": "admin@test.com",
"alias": "系统管理员",
"avatar": "xxxxxxx",
"token": null
}
删除用户
topic
sso_delete_user
msg
{
"userId": 1
}
用户退出
topic
sso_user_logout
msg
{
"token": "xxxxxxxxxx"
}
其它子系统通过token获取用户授权信息
获取用户信息接口
URL
GET /auth/getUserInfoByToken
请求参数
token: 用户token，必填，字符串类型
成功响应
- 内容类型: application/json
{
"success": true,
"data": {
"userId":12,
"userName":"admin",
"expirationTimeMillis":1711093823000
}
}
失败响应
- 内容类型: application/json
{
"success": false,
"data": null,
"msg":"token已过期或无效"
}
总结
总的来说，本文介绍了单点登录（SSO）的概念、好处、实现方式、原理以及系统间交互的方式。单点登录通过一次登录即可访问多个相关系统，提高了用户体验、减轻了用户的记忆负担，同时增强了系统的安全性。
基于Cookie和基于Token是两种常见的实现方式，前者简单但安全性较低，后者安全性高但实现较为复杂。单点登录的原理在于需要一个独立的认证中心来进行身份验证，并通过令牌实现各个系统之间的无缝切换。前端需要处理登录页面、跳转、Token管理等逻辑。系统间交互通过消息队列和接口调用来实现用户信息的同步更新和授权验证。
综合来看，单点登录是一项重要的身份验证机制，为用户和企业带来了诸多优势，是现代应用和企业系统中不可或缺的功能。
193
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
