目录
1.什么是单点登录?
单点登录(Single Sign-On,简称SSO)是一种身份认证机制,允许用户在一个地方登录后,即可访问多个相关但独立的系统或应用程序,而不需要在每个系统中重新登录。
主要特点
-
一次登录,多次访问:用户只需要在一个系统中进行一次身份验证,就可以在其他相关系统中自动获得访问权限,而不需要重复输入用户名和密码。
-
集中管理:用户的认证过程通常集中管理在一个统一的身份认证服务(如CAS、OAuth、SAML等)中,这有助于简化用户管理,提高安全性,并减少密码疲劳。
-
增强用户体验:SSO极大地简化了用户的使用体验,特别是在企业内部或跨多个子系统的应用场景中,用户不需要记住多个账户或反复登录。
工作原理(简化版)
-
用户登录:用户在某个应用系统(通常称为“客户端”)访问受保护的资源,发现未登录时,会被重定向到统一的认证服务器。
-
身份验证:用户在认证服务器上输入凭据(用户名、密码等),认证服务器验证用户身份。验证成功后,认证服务器生成一个令牌或票据,作为用户登录的凭证。
-
分发凭证:认证服务器将这个凭证返回给初始请求的客户端,客户端保存这个凭证(通常是通过Cookie或Token)。
-
访问其他系统:当用户访问其他相关系统时,这些系统通过共享的凭证验证用户身份。如果凭证有效,用户即可访问该系统资源,而无需再次登录。
常见应用场景
-
企业内部应用:在企业内部,员工通常需要访问多个系统,如邮件系统、内部社交平台、办公自动化系统等。SSO使员工只需一次登录即可访问所有这些系统。
-
跨域网站登录:许多网站允许用户通过第三方账号(如Google、Facebook等)进行登录,这也是一种SSO的实现方式。
-
云服务:在云计算环境中,用户往往需要访问多个云服务提供商提供的应用,通过SSO可以简化跨应用的登录流程。
优点
- 提高效率:减少了用户登录的次数,简化了用户的操作流程。
- 增强安全性:减少了密码暴露的风险,因为用户只需要输入一次凭据。
- 集中管理:管理员可以更容易地管理用户的权限和访问控制。
2.cookie,session的区别
Cookie
和Session
是Web开发中常用的两种机制,用于在HTTP请求之间保存用户状态信息。虽然它们都用于存储用户的会话信息,但它们的工作原理、存储位置和使用场景有所不同。
Cookie
1. 存储位置:
Cookie
是存储在客户端(即用户的浏览器)上的小型文本文件。服务器通过HTTP响应将Cookie
发送到浏览器,浏览器会将Cookie
保存,并在后续的请求中将其发送回服务器。
2. 生命周期:
Cookie
可以有指定的过期时间。如果未设置过期时间,则Cookie
在会话结束时(即关闭浏览器)会被删除;如果设置了过期时间,则在指定的时间点过期并删除。
3. 安全性:
- 由于
Cookie
存储在客户端,它们可能被用户或恶意程序查看和修改。因此,Cookie
中不应该存储敏感信息(如密码)。可以通过设置HttpOnly
标志防止客户端脚本(如JavaScript)访问Cookie
,并通过Secure
标志确保Cookie
只能通过HTTPS传输。
4. 大小限制:
Cookie
的大小通常有限制(一般为4KB),并且每个域名下的Cookie
数量也有限制。
5. 使用场景:
Cookie
常用于保存一些不太敏感的、需要在多个请求中持久化的信息,如用户偏好设置、语言选择、广告跟踪等。
Session
1. 存储位置:
Session
是存储在服务器上的数据结构,用于保存用户的会话信息。每个用户会话有一个唯一的Session ID
,这个ID通常存储在客户端的Cookie
中,也可以通过URL参数传递。
2. 生命周期:
Session
的生命周期通常与用户会话相关联。当用户关闭浏览器或会话超时时,Session
会过期并被销毁。Session
的超时时间可以在服务器上配置。
3. 安全性:
- 由于
Session
数据存储在服务器端,相对来说比存储在客户端的Cookie
更加安全。服务器只依赖Session ID
来访问用户数据,不会将敏感数据暴露给客户端。
4. 大小限制:
Session
的大小仅受服务器存储空间的限制,相对于Cookie
,可以存储更多的数据。
5. 使用场景:
Session
常用于保存敏感的用户信息和需要在多个页面之间共享的临时数据,如用户登录状态、购物车内容等。
区别总结
- 存储位置:
Cookie
存储在客户端,Session
存储在服务器端。 - 安全性:
Session
更安全,因为敏感信息不暴露给客户端。Cookie
容易受到安全威胁,如XSS(跨站脚本攻击)。 - 生命周期:
Cookie
可以持久化保存到客户端,Session
通常在会话结束或超时后失效。 - 数据容量:
Cookie
的大小有限,通常为4KB,而Session
的数据容量则依赖于服务器的存储能力。 - 使用场景:
Cookie
适合存储一些不敏感且需要在客户端持久化的数据,Session
则适合存储敏感的会话信息和临时数据。
3.几种单点登录的方式
3.1 基于Cookie的SSO(传统)
1. 基于Cookie的SSO
原理: 基于Cookie的SSO利用了浏览器在同一域或子域之间共享Cookie的能力。当用户在一个应用上登录后,服务器会在用户浏览器上设置一个Cookie。其他同一域或子域下的应用可以访问这个Cookie,从而判断用户的登录状态。
特点:
- 简单且直接。
- 适用于同一域或子域下的多个应用系统。
- 存在跨域限制,难以在不同域名间共享。
流程:
- 用户在应用A上登录,应用A在用户浏览器上设置Cookie。
- 用户访问应用B,应用B读取Cookie,判断用户已登录,从而允许访问。
3.2 基于令牌的SSO(Token-based SSO)
基于令牌的单点登录(Token-based SSO)是一种通过使用安全令牌(Token)来实现用户身份验证和授权的机制。在这种方式中,用户登录一次后,服务器生成一个令牌,并在随后的请求中使用该令牌来验证用户的身份。JSON Web Token (JWT) 是最常用的令牌格式之一。
工作原理
-
用户登录:
- 用户访问需要认证的资源,系统检测到用户未登录,将用户重定向到认证服务器(Authorization Server)。
- 用户在认证服务器上输入凭据(如用户名和密码),进行身份验证。
-
生成令牌:
- 如果用户凭据有效,认证服务器生成一个令牌(通常是JWT),该令牌包含了用户的身份信息和授权信息,并通过签名保护其完整性。
- 令牌可能会包括一些声明(claims),如用户ID、过期时间、权限等信息。
-
返回令牌:
- 认证服务器将生成的令牌返回给用户的客户端(例如浏览器或移动应用)。客户端通常会将令牌存储在浏览器的Local Storage、Session Storage,或作为Cookie。
-
令牌验证:
- 用户访问其他受保护的资源时,客户端会将令牌附加到HTTP请求的头部(通常是
Authorization: Bearer <token>
)。 - 应用服务器接收到请求后,验证令牌的有效性(检查签名、过期时间、用户权限等)。
- 如果令牌有效,服务器允许用户访问资源,否则返回未授权错误。
- 用户访问其他受保护的资源时,客户端会将令牌附加到HTTP请求的头部(通常是
-
访问资源:
- 验证通过后,服务器根据令牌中的用户信息提供相应的服务,用户无需再次登录即可访问其他相关系统。
优点
- 跨域支持: 令牌可以在不同域之间传递,适用于分布式系统和跨域请求场景。
- 无状态: 服务器不需要保存会话数据,令牌中包含了所有必要的信息,使得应用更加可扩展。
- 灵活性高: 令牌可以包含丰富的用户信息和权限数据,并且可以设置精细的过期时间。
- 单点故障少: 因为服务器不需要维护用户会话状态,令牌机制可以减少单点故障的风险。
缺点
- 令牌失效管理复杂: 一旦令牌签发,直到令牌过期之前,令牌都是有效的,因此在令牌丢失或被盗用的情况下,无法立即注销已发出的令牌。
- 安全性依赖传输和存储: 需要确保令牌的传输(如HTTPS)和存储(如本地存储)的安全,防止令牌被窃取。
3.3 基于OAuth的SSO
原理: OAuth 2.0和OpenID Connect(OIDC)是常用的授权和身份验证协议,适用于跨应用、跨域的SSO场景。OAuth 2.0主要用于授权,而OIDC则是在OAuth 2.0基础上添加了身份验证层。用户在OAuth/OIDC提供者处登录并授权后,客户端应用可以获得访问令牌和ID令牌,用于访问资源服务器和获取用户信息。
实现步骤:
- 用户访问应用A,应用A将用户重定向到OAuth/OIDC认证服务器进行登录。
- 用户登录并授权后,OAuth/OIDC认证服务器将授权码或令牌返回给应用A。
- 应用A使用授权码从认证服务器换取访问令牌和ID令牌。
- 应用A使用访问令牌访问资源服务器,使用ID令牌获取用户身份信息。
- 当用户访问应用B时,重复上述流程,但由于用户已经登录,认证服务器会直接返回令牌,实现无缝登录。
优点:
- 支持跨域、跨应用的单点登录。
- 安全性高,支持细粒度的权限管理和身份验证。
- 广泛应用于第三方登录,如使用Google、Facebook账户登录。
缺点:
- 实现较为复杂,涉及OAuth 2.0和OIDC协议的理解和实现。
- 需要管理Token的安全性和生命周期。
总结
- 基于Cookie的SSO适合同一域名或子域名下的简单应用,但对跨域支持不友好。
- 基于令牌的SSO使用JWT等Token进行跨域单点登录,适合分布式系统,但需要妥善管理Token。
- 基于OAuth/OpenID Connect的SSO是现代应用中最常见和最安全的方式,尤其适用于跨域、跨应用的场景,但实现复杂度较高。
3.4 基于Redis与Session结合的方式
将Redis与Session结合使用可以进一步提升单点登录(SSO)的性能和可扩展性。通过Redis来管理Session数据,可以实现分布式Session管理,确保在多台服务器间共享用户的登录状态。
方案概述
在这种架构下,所有的应用程序(比如AppA
和AppB
)在用户登录后,不再将Session数据保存在各自的本地内存中,而是统一存储到Redis中。这样无论用户请求落在哪台服务器上,都可以通过Redis访问到同样的Session数据,从而实现SSO。
实现步骤
-
用户请求登录:
- 用户访问
AppA
,AppA
检测用户未登录,将用户重定向到CAS进行登录。 - 用户在CAS登录成功后,CAS生成一个全局唯一的Session ID(通常使用JWT或其他唯一标识符)。
- CAS将Session ID返回给
AppA
,AppA
将Session数据(如用户信息)存储到Redis中,使用Session ID
作为键。
- 用户访问
-
应用程序获取Session:
- 当用户访问
AppA
或者AppB
时,应用程序从请求中获取Session ID,并通过Redis查询相应的Session数据。 - 如果Session存在且有效,应用程序从Redis中加载用户信息,实现自动登录。
- 当用户访问
-
Session过期和注销:
- Session的有效期可以在Redis中设置TTL(Time To Live,生存时间)。
- 当用户注销时,应用程序删除Redis中的Session数据,并通知其他应用程序(如果有必要)。
除了以上方法,还有报错cookie+session的方式,结合CAS的方式等,更增加了单点登录在不同维度的安全性。