关于后端:面试官说说SSO单点登录的实现原理

2次阅读

共计 3209 个字符，预计需要花费 9 分钟才能阅读完成。

单点登录（Single Sign-On, SSO）是一种让用户在多个利用零碎之间只需登录一次就能够拜访所有受权零碎的机制。单点登录次要目标是为了进步用户体验并简化平安治理。

举个例子，您在一个大型企业工作，该企业领有一套由多个独立应用程序组成的生态系统，例如：外部邮箱零碎、我的项目管理系统、员工自助服务零碎、人力资源信息系统等。

而这些零碎在没有施行单点登录的状况下会呈现以下问题：

用户体验方面 ：每天开始工作时，员工须要别离登录每一个零碎能力失常发展工作，这不仅耗时，而且容易造成明码疲劳，即频繁记忆和输出不同零碎的登录凭证，升高了工作效率。举例：员工小王每天下班要先登录外部邮箱查看重要告诉，而后切换至我的项目管理系统更新进度，接着进入人力资源信息系统查看工资单。如果没有 SSO，他须要在每个零碎独自输出用户名和明码。
平安治理方面 ：各个系统间的明码策略可能不统一，员工可能会因为难以记忆而在多个零碎应用同一明码，减少了数据泄露的危险。同时，管理员对用户账户的治理、权限变更及审计也会变得复杂。举例：若小王在每个零碎应用雷同明码，一旦某一零碎存在安全隐患导致明码泄露，攻击者就有可能借此尝试登录其余零碎。而有了 SSO，管理员只需在一处更改或撤销小王的登录权限，就能影响所有相干零碎。

采纳单点登录后，小王只需在一天开始时登录一次，之后拜访其余所有零碎时都将自动识别其身份并受权拜访，无需再次验证。这样既缩小了用户登录累赘，又进步了安全性，因为管理员能够通过对立的入口更无效地执行身份验证、受权以及审计策略。同时，SSO 还能够配合多因素认证（MFA）等加强措施，进一步晋升整个零碎的安全级别。

单点登录是在用户登录一个业务零碎时，先将登录信息发送至独自的 SSO 服务器进行认证，如果认证胜利则向该应用程序或零碎发送受权令牌，之后该用户就能够应用受权令牌实现登录并操作所有零碎了。

独自登录通常的操作流程是这样的：

用户认证：
- 用户首先拜访一个零碎，输出用户名和明码进行登录。
- 登录申请被发送到专门的认证核心（Authentication Server）。
- 认证核心验证用户的身份信息，如果验证胜利，则生成一个平安令牌（如 JWT、Ticket 等）。
令牌发放与传递：
- 认证核心将令牌返回给用户首次登录的利用零碎。
- 利用零碎将令牌存储在用户的本地会话（如浏览器的 Cookie）中。
- 当用户拜访其余须要 SSO 反对的利用零碎时，浏览器会携带令牌主动发送给指标零碎。
令牌验证与受权：
- 指标零碎接管到申请后，发现携带了令牌，则将令牌发送给认证核心进行验证。
- 认证核心验证令牌的有效性（包含签名、有效期等）。
- 如果令牌无效，认证核心会返回一个确认信息给指标零碎，证实用户已通过认证。
资源共享与受权：
- 指标零碎接管到认证核心的确认后，容许用户拜访系统资源，而无需再次登录。
- 指标零碎能够根据令牌中的信息进行权限管制和角色映射。
会话治理：
- 为了保障安全性，个别会设置令牌的有效期，过了有效期后须要从新认证。
- 在某些实现中，当用户在一个子系统中登记时，会告诉认证核心撤销所有关联令牌，从而实现全局登记，保障了其余零碎也无奈持续应用过期的认证信息。

在技术实现上，单点登录能够借助如 CAS（Central Authentication Service）、OAuth、OpenID Connect 等标准协议，也能够基于企业外部的自定义协定实现。在整个流程中，要害是要保护一个全局认可的信赖票证（token），并通过集中式的认证服务中心来进行身份的对立治理和验证。

在 Java 我的项目中，实现单点登录（SSO）的计划次要有以下几种：

OAuth2 + JWT（JSON Web Tokens）计划 ：OAuth2 是一个凋谢规范，容许用户受权第三方利用拜访他们在服务提供商处存储的特定信息，而不须要将用户名和明码提供给第三方利用。JWT 是一种用于身份验证和受权的令牌，通常与 OAuth2 一起应用。在 Spring Boot 中，你能够应用 Spring Security OAuth2 和 JWT 库来实现这种计划。
CAS（Central Authentication Service）单点登录计划 ：CAS 是一个开源的、用于企业级的单点登录解决方案。它提供了一套服务端和客户端的组件，使得在多个利用之间实现单点登录变得简略。在 Spring Boot 中，你能够应用 Spring Security CAS 客户端来实现这种计划。
Spring Security + OAuth2：Spring Security 是一个提供身份验证和受权性能的框架，它能够与 OAuth2 一起应用来实现单点登录。在这种计划中，你能够应用 Spring Security 来解决用户的身份验证和受权，而后应用 OAuth2 来治理用户在多个利用之间的拜访。
Spring Session：Spring Session 是一个用于治理用户会话的框架，它能够帮忙你在多个利用之间共享会话信息，从而实现单点登录。你能够应用 Spring Session 来将会话信息存储在共享的中央（如 Redis），而后在每个利用中通过 Spring Session 来拜访这些会话信息。

其中，OAuth2 + JWT 计划适宜于须要对外提供 API 接口的利用，而 CAS 计划则更适宜于外部零碎之间的单点登录。Spring Security + OAuth2 计划则是一种比拟通用的抉择，既能够解决外部零碎的单点登录，也能够解决对外提供 API 接口的状况。Spring Session 计划则更适宜于须要将会话信息共享到多个利用之间的场景，它也是最早和最简略的单点登录实现形式。

SSO 和 OAuth2 都是用于治理用户身份验证和受权的协定，但它们的指标和利用场景有所不同，具体区别如下：

指标：
SSO 的次要指标是简化用户在多个利用零碎中的登录流程，让用户只须要登录一次就能够拜访所有受权的利用零碎，进步用户体验和效率。
OAuth2 的次要指标是容许第三方利用代表用户取得拜访特定资源的权限，同时爱护用户的敏感信息（如明码）不被泄露。
利用场景：
SSO 通常用于大型企业外部或相关联的零碎之间，用户只须要在一个中央（如企业门户）进行登录，就能够拜访多个外部零碎。
OAuth2 广泛应用于第三方利用须要拜访用户存储在服务提供商（如 Google、Facebook）中的资源时，用户受权第三方利用拜访其资源，而无需将用户名和明码间接提供给第三方利用。
实现形式：
SSO 的实现通常依赖于一个集中的认证核心（Authentication Server），用户在这个核心进行登录，并取得一个全局会话或令牌（Token），而后在拜访其余利用零碎时，这个令牌会被用来验证用户的身份和权限。
OAuth2 的实现波及四个角色：资源所有者（Resource Owner）、受权服务器（Authorization Server）、客户端（Client）和资源服务器（Resource Server）。用户（资源所有者）受权客户端拜访其资源，受权服务器颁发拜访令牌给客户端，客户端应用这个令牌拜访资源服务器上的资源。

PS：SSO 和 OAuth2 都是用于治理用户身份验证和受权的协定，但 SSO 更重视于简化用户在多个利用零碎中的登录流程，而 OAuth2 更重视于爱护用户的敏感信息，并容许第三方利用代表用户拜访特定资源。在理论利用中，它们能够互相联合应用，例如应用 OAuth2 来实现 SSO 中的令牌颁发和验证过程。