SSO 单点登录和 OAuth2.0 有何区别？

• 1 单点登录（SSO）

• 2 OAuth2.0

• 3 SSO 与 OAuth2.0

---

在微服务时代，用户需要在多个应用程序和服务之间进行无缝切换，同时保持其登录状态。我们可以通过单点登录（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 提供了丰富的功能和安全性，但它也相对复杂，需要仔细配置和管理。

• 基于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 的话，主要有如下几种主流框架：

1. Spring Security OAuth：Spring Security OAuth 是 Spring框架的一个扩展，提供了对 OAuth2 协议的全面支持。它允许开发者在 Spring 应用程序中轻松实现 OAuth2 认证和授权流程，包括授权服务器、资源服务器和客户端应用程序的配置。

2. Keycloak：Keycloak 是一个开源的身份和访问管理解决方案，它支持 OAuth2、OpenID Connect 和其他身份协议。Keycloak 提供了一个易于使用的管理界面，允许开发者配置和管理 OAuth2 相关的设置，如客户端、用户和角色等。

3. Apache Oltu：Apache Oltu 是一个实现了 OAuth2 协议的 Java 库，它提供了对 OAuth2 流程的抽象和简化。Oltu 可以帮助开发者快速构建 OAuth2 客户端和服务器组件，并支持多种授权流程，如授权码流程、隐式流程等。

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

3 SSO 与 OAuth2.0OAuth2.0

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

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

SSO是Single Sign On的缩写，OAuth是Open Authority的缩写，这两者都是使用令牌的方式来代替用户密码访问应用。流程上来说他们非常相似，但概念上又十分不同。很多人会将其混为一谈，其实这两个还是有些区别的

对于OAuth2.0相关内容在Spring Cloud Alibaba 实战中结合实战项目源码从零搭建有着详细的介绍，如下图：

什么是单点登录

简单的说就是在多个应用的系统中，用户只需要登录一次就可以访问权限范围内的所有应用子系统，同样的注销也只需要注销一次。

比如百度这个网站，用户只要登录了百度的官网，那么对于百度百科、百度知道、百度贴吧等网站都是处于登录状态，这就是一个典型的单点登录的例子。

单点登录和Oauth2.0的区别

虽然Oauth2.0能够实现单点登录，但是在一些方面还是有些区别的，如下：

1. 信任角度：Oauth2.0授权服务端和第三方客户端不属于一个互相信任的应用群，比如微信和第三方，这就不是一个公司的产品；然而单点登录的服务端和接入的客户端都在同一个相互信任的应用系统中，比如百度官网、百度百科，这都是一个公司的产品

2. 资源角度：OAuth2.0授权主要是让用户自行决定——“我”在OAuth2.0服务提供方的个人资源是否允许第三方应用访问；而单点登录的资源都在客户端这边，单点登录的服务端主要用于登录，以及管理用户在各个子系统的权限信息。

3. 流程角度：OAuth2.0授权的时候，第三方客户端需要拿预先“商量”好的密码去获取Access Token；而单点登录则不需要。

Oauth2.0完全可以实现单点登录，但是更加侧重于对于己方资源的保护，了解了这两种的区别才能正确的选择

单点登录的实现

Oauth2.0实现单点登录非常简单，比如微服务下的各个子系统接入Oauth2.0的认证服务，用户从认证服务获取token后，直接通过网关转发给下游子系统则可以实现只需要一次登录

其实除了Oauth2.0以外，还有很多框架能够实现单点登录，比较经典则是CAS框架

以下是CAS框架的官方流程图。特别注意：SSO是一种思想，而CAS只是实现这种思想的一种框架而已

上面的流程大概为：

1. 用户输入网址进入业务系统Protected App，系统发现用户未登录，将用户重定向到单点登录系统CAS Server，并带上自身地址service参数

2. 用户浏览器重定向到单点登录系统，系统检查该用户是否登录，这是SSO(这里是CAS)系统的第一个接口，该接口如果用户未登录，则将用户重定向到登录界面，如果已登录，则设置全局session，并重定向到业务系统

3. 用户填写密码后提交登录，注意此时的登录界面是SSO系统提供的，只有SSO系统保存了用户的密码

4. SSO系统验证密码是否正确，若正确则重定向到业务系统，并带上SSO系统的签发的ticket

5. 浏览器重定向到业务系统的登录接口，这个登录接口是不需要密码的，而是带上SSO的ticket，业务系统拿着ticket请求SSO系统，获取用户信息。并设置局部session，表示登录成功返回给浏览器sessionId(tomcat中叫JSESSIONID)

6. 之后所有的交互用sessionId与业务系统交互即可

整个流程还是相对比较复杂的，当然CAS这个框架的配置也是相对比较复杂，了解过的人都想放弃，关于CAS如何去搭建，在后面会单独介绍

最常见的例子是，我们打开淘宝APP，首页就会有天猫、聚划算等服务的链接，当你点击以后就直接跳过去了，并没有让你再登录一次

总结

Oauth2.0和单点登录的区别需要理解清楚，相对来说Oauth2.0实现单点登录更加简单，CAS虽然能够实现单点登录，但是服务部署和配置更加复杂，不易于上手，当然目前也有很多的系统在使用CAS，在选择的时候开发者根据这些区别和复杂程度去决策。

https://mp.weixin.qq.com/s/K_TelAXMHyWgm4d9v5tGSQ