SSO单点登录和OAuth2.0区别小结

2025-12-13 0 481

在微服务时代,用户需要在多个应用程序和服务之间进行无缝切换,同时保持其登录状态。我们可以通过单点登录(SSO)或者 OAuth2.0 等身份验证和授权协议来实现这一目标。

1、单点登录(SSO)

单点登录(SSO)是一种身份验证方法,允许用户在一个应用程序或服务中登录后,无需再次输入凭据即可访问其他相关应用程序或服务。这种方法通过将登录认证和业务系统分离,使用独立的登录中心,实现了在登录中心登录后,所有相关的业务系统都能免登录访问资源。

SSO 单点登录的方案实际上有很多种:

  • 基于会话的单点登录(Session-Based SSO):

这是最早和最简单的单点登录实现方式。当用户在第一个应用程序中登录时,服务器会创建一个会话,并将该会话 ID 存储在用户的浏览器中(通常是通过 Cookie)。当用户访问其他应用程序时,浏览器会发送该会话 ID,从而允许服务器验证用户的身份。此方法的缺点是它依赖于浏览器和会话状态,对于分布式或者微服务系统而言,可能需要在服务端做会话共享,但是服务端会话共享效率比较低,这不是一个好的方案。对这种方案感兴趣的话可以看看松哥之前发的 Spring Session 会话共享的文章。

  • 基于令牌的单点登录(Token-Based SSO):

这种方法通常使用 JSON Web Tokens(JWT)或类似的令牌格式。当用户在第一个应用程序中登录时,服务器会生成一个包含用户信息的令牌,并将其发送给客户端(通常是浏览器)。客户端会存储这个令牌,并在访问其他应用程序时将其作为请求的一部分发送。应用程序会验证令牌的有效性,并据此授予用户访问权限。这种方法更加安全和灵活,因为它不依赖于会话状态,可以在多个域和服务器之间工作。这种方案实际上有很多变种,但是目前大部分的分布式项目单点登录基本上都是这种方案,或者是基于这种方案衍生出来的变种方案。

  • 基于 OAuth 的单点登录(OAuth-Based SSO):

OAuth 是一个开放标准,允许用户授权第三方应用程序访问其存储在另一个服务提供商上的信息,而无需将用户名和密码提供给该第三方应用程序。OAuth2.0 是最常用的版本,它支持多种授权流程,包括授权码流程、隐式流程和客户端凭据流程。

在单点登录的上下文中,OAuth 可以用作一个中介,用户在一个“授权服务器”上登录,并获得一个访问令牌,该令牌可以用于访问其他“资源服务器”上的资源。OAuth 提供了丰富的功能和安全性,但它也相对复杂,需要仔细配置和管理。松哥之前也专门写过 OAuth2 相关的教程,大家在公众号后台回复 oauth2 有链接。

  • 基于SAML的单点登录(SAML-Based SSO):

SAML(Security Assertion Markup Language)是一种 XML 框架,用于在不同安全域之间交换身份验证和授权信息。SAML 允许一个实体(通常是身份提供商或 IdP)向另一个实体(通常是服务提供商或 SP)发送安全断言,证明用户已经成功登录。SAML 通常与 OAuth 结合使用,以提供更强大和灵活的单点登录解决方案。但是 SAML 比较复杂,所以维护起来可能会有压力。

回到具体的生产环境,选择哪种单点登录方案取决于具体的需求和环境。对于是分布式但是又比较简单的内部应用程序,基于会话的 SSO 可能就足够了。但是大型分布式系统,基于令牌或 OAuth 的 SSO 可能更合适。小伙伴还是要结合自己的实际项目去选择。

2、OAuth2.0

OAuth2.0 是一种开放授权协议,允许用户授权第三方应用程序访问其存储在服务提供商(如QQ、WeiXin、抖音等)上的特定资源。与 SSO 类似,OAuth2.0 也使用了令牌的概念来实现身份验证和授权。

OAuth2.0 定义了四种授权模式,分别是:

  • 授权码模式
  • 隐式模式
  • 密码模式
  • 客户端模式

其中,授权码模式是最常用的一种模式,适用于那些有后端的 Web 应用程序。在这种模式下,第三方应用程序首先向授权服务器申请一个授权码,然后使用这个授权码向授权服务器请求访问令牌。一旦获得访问令牌,第三方应用程序就可以使用这个令牌访问用户授权的资源。

注意,OAuth2.0 并不直接实现单点登录功能。它主要关注授权和访问控制,允许用户授权第三方应用程序访问其资源。然而,通过与其他技术(如SSO)结合使用,OAuth2.0 可以实现单点登录的效果。

目前来说,如果你想在项目中使用 OAuth2 的话,主要有如下几种主流框架:

  • Spring Security OAuth:Spring Security OAuth 是 Spring框架的一个扩展,提供了对 OAuth2 协议的全面支持。它允许开发者在 Spring 应用程序中轻松实现 OAuth2 认证和授权流程,包括授权服务器、资源服务器和客户端应用程序的配置。
  • Keycloak:Keycloak 是一个开源的身份和访问管理解决方案,它支持 OAuth2、OpenID Connect 和其他身份协议。Keycloak 提供了一个易于使用的管理界面,允许开发者配置和管理 OAuth2 相关的设置,如客户端、用户和角色等。
  • Apache Oltu:Apache Oltu 是一个实现了 OAuth2 协议的 Java 库,它提供了对 OAuth2 流程的抽象和简化。Oltu 可以帮助开发者快速构建 OAuth2 客户端和服务器组件,并支持多种授权流程,如授权码流程、隐式流程等。

这些框架和库提供了 OAuth2 协议的完整实现,包括令牌生成、验证、刷新、撤销等。它们简化了 OAuth2 流程的集成,使得开发者能够专注于业务逻辑的实现,而无需过多关注底层的认证和授权细节。

3、SSO 与 OAuth2.0

首先,SSO 主要关注用户在多个应用程序和服务之间的无缝切换和保持登录状态的问题。它通过独立的登录中心来实现这一目标,使用户只需在一个地方输入凭据即可访问所有相关应用程序和服务。而 OAuth2.0 则主要关注授权和访问控制的问题,允许用户授权第三方应用程序访问其存储在服务提供商上的特定资源。

其次,SSO 通常只涉及用户、登录中心和业务系统之间的交互,而 OAuth2.0 则涉及用户、第三方应用程序、授权服务器和资源服务器之间的交互。这使得 OAuth2.0 更加复杂和灵活,适用于多种场景和应用程序类型。

到此这篇关于SSO单点登录和OAuth2.0区别小结的文章就介绍到这了,更多相关SSO单点登录 OAuth2.0内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

收藏 (0) 打赏

感谢您的支持,我会继续努力的!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

申明:本文由第三方发布,内容仅代表作者观点,与本网站无关。对本文以及其中全部或者部分内容的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。本网发布或转载文章出于传递更多信息之目的,并不意味着赞同其观点或证实其描述,也不代表本网对其真实性负责。

左子网 编程相关 SSO单点登录和OAuth2.0区别小结 https://www.zuozi.net/36648.html

常见问题
  • 1、自动:拍下后,点击(下载)链接即可下载;2、手动:拍下后,联系卖家发放即可或者联系官方找开发者发货。
查看详情
  • 1、源码默认交易周期:手动发货商品为1-3天,并且用户付款金额将会进入平台担保直到交易完成或者3-7天即可发放,如遇纠纷无限期延长收款金额直至纠纷解决或者退款!;
查看详情
  • 1、描述:源码描述(含标题)与实际源码不一致的(例:货不对板); 2、演示:有演示站时,与实际源码小于95%一致的(但描述中有”不保证完全一样、有变化的可能性”类似显著声明的除外); 3、发货:不发货可无理由退款; 4、安装:免费提供安装服务的源码但卖家不履行的; 5、收费:价格虚标,额外收取其他费用的(但描述中有显著声明或双方交易前有商定的除外); 6、其他:如质量方面的硬性常规问题BUG等。 注:经核实符合上述任一,均支持退款,但卖家予以积极解决问题则除外。
查看详情
  • 1、左子会对双方交易的过程及交易商品的快照进行永久存档,以确保交易的真实、有效、安全! 2、左子无法对如“永久包更新”、“永久技术支持”等类似交易之后的商家承诺做担保,请买家自行鉴别; 3、在源码同时有网站演示与图片演示,且站演与图演不一致时,默认按图演作为纠纷评判依据(特别声明或有商定除外); 4、在没有”无任何正当退款依据”的前提下,商品写有”一旦售出,概不支持退款”等类似的声明,视为无效声明; 5、在未拍下前,双方在QQ上所商定的交易内容,亦可成为纠纷评判依据(商定与描述冲突时,商定为准); 6、因聊天记录可作为纠纷评判依据,故双方联系时,只与对方在左子上所留的QQ、手机号沟通,以防对方不承认自我承诺。 7、虽然交易产生纠纷的几率很小,但一定要保留如聊天记录、手机短信等这样的重要信息,以防产生纠纷时便于左子介入快速处理。
查看详情

相关文章

猜你喜欢
发表评论
暂无评论
官方客服团队

为您解决烦忧 - 24小时在线 专业服务