单点登录SSO与OAuth2.0授权核心概念与授权码模式详解

SSO (Single Sign On，单点登录) 和 OAuth (Open Authority，开放授权) 2.0 都是利用令牌代替传统的用户名和密码来访问应用的技术方案。从流程上看，它们非常相似，但本质上要解决的核心问题却不同。SSO 大家可能更熟悉，它将认证中心与业务系统分离，用户在独立的登录中心认证一次后，即可访问所有关联的系统而无需再次登录。

OAuth2.0 的原理或许陌生，但其应用场景无处不在。比如，当你在一个网站想留言却不想注册时，选择了“使用微信登录”——这背后正是 OAuth2.0 在发挥作用。无论是 SSO 还是 OAuth2.0，你的账号和密码都并不存储在正在访问的业务系统中，而是存放在认证中心（如公司的统一登录平台）或资源所有者（如微信）的服务器上。这正是“用令牌代替密码”思想的体现。

一、SSO：单点登录的核心思想与实现

为了更好地区分和理解，我们先深入探讨 SSO。SSO 本身是一种架构思想或解决方案，旨在实现一处登录，处处通行。实现这一思想的框架有很多，CAS (Central Authentication Service) 就是其中一种广为人知的实现方案。请务必记住：SSO是思想，而CAS只是实现这种思想的一种框架。

下图是 CAS 官方提供的标准单点登录时序图，清晰展示了其工作流程：

整个流程可以概括为以下几个关键步骤：

1. 用户访问受保护应用：用户尝试访问业务系统 Protected App。该系统发现用户未登录（无有效会话），于是将用户重定向到单点登录服务器 CAS Server，并在重定向地址中附带一个 service 参数，用于标识当前业务系统的回调地址。
2. SSO服务器检查会话：用户的浏览器被重定向到 CAS Server。CAS 服务器检查用户是否已经拥有全局的 SSO 会话（例如通过名为 CASTGC 的 Cookie 携带的 TGT）。如果未登录，则向用户展示登录表单；如果已登录，则直接进入第4步。
3. 用户提交认证信息：用户在 CAS 提供的登录页面输入用户名和密码并提交。请注意，只有 SSO 服务器保存了用户的真实密码，业务系统不感知密码。
4. CAS验证并创建会话：CAS 服务器验证凭据。若成功，则创建一个全局的 SSO 会话，并生成一个临时的“票据授予票据”存储起来（常通过 CASTGC Cookie 返回给浏览器）。同时，CAS 会生成一个一次性的服务票据，并携带此票据将浏览器重定向回最初访问的业务系统地址。
5. 业务系统验证票据：浏览器带着服务票据访问业务系统的登录接口。业务系统在后台（服务器间通信）拿着这个票据去询问 CAS 服务器：“这个票据有效吗？对应的用户是谁？” CAS 验证票据后返回用户身份信息。
6. 建立局部会话：业务系统获取用户信息后，为其创建一个局部会话（例如设置 JSESSIONID），并将此会话标识返回给浏览器。至此，用户在该业务系统登录成功。
7. 后续访问：之后用户在访问该业务系统时，只需携带局部会话的 JSESSIONID 即可，无需再与 CAS 服务器交互。

一个大家最熟悉的 SSO 例子就是阿里巴巴的生态应用。打开淘宝APP，首页有天猫、饿了么、飞猪等众多服务的入口。当你点击进入这些应用时，无需重新登录，这就是典型的单点登录体验。

这种跨系统、跨应用的流畅访问体验，正是 SSO 为 System Design 中的用户体验和权限管理带来的核心价值。

二、OAuth2.0：开放授权的标准协议

OAuth2.0 的流程与 SSO 有相似之处，但其设计初衷并非为了解决“一次登录，访问多个内部系统”的问题。OAuth2.0 是一种授权协议，它允许用户授权第三方应用访问其存储在另一个服务提供商处的资源，而无需向第三方应用暴露自己的密码。

在 OAuth2.0 的授权码模式（最常用、最安全的模式）中，通常包含以下几个角色：

• 资源所有者 (Resource Owner)：即用户本人。
• 客户端 (Client)：希望访问用户资源的第三方应用。
• 授权服务器 (Authorization Server)：验证用户身份并颁发令牌的服务器（如微信登录的服务器）。
• 资源服务器 (Resource Server)：存放用户受保护资源的服务器（如存放微信头像、昵称的服务器，常与授权服务器是同一个）。

当我们借用 OAuth2.0 来实现类似 SSO 的效果时，通常不需要区分资源服务器，只需要授权服务器和客户端（即我们的业务系统）就够了。授权服务器负责认证和发令牌，客户端使用令牌来获取用户的基本信息（此时用户信息就是被访问的“资源”）。

一个典型的 OAuth2.0 授权码模式流程如下：

1. 用户发起授权请求：用户在某网站点击“微信登录”。该网站（客户端）将用户重定向到微信的授权服务器，并带上自己的身份标识和回调地址。
2. 用户确认授权：用户跳转到微信提供的授权页面（而非第三方网站页面），确认是否允许该网站获取自己的基本信息。
3. 授权服务器颁发授权码：用户同意授权后，微信授权服务器生成一个授权码，并将浏览器重定向回第三方网站的回调地址，并附上这个授权码。
4. 客户端交换访问令牌：第三方网站的服务器在后台，使用这个授权码、自己的身份标识和密钥，向微信授权服务器请求交换一个访问令牌。
5. 使用令牌访问资源：第三方网站拿到访问令牌后，即可用此令牌去请求微信的资源服务器，获取用户的昵称、头像等授权范围许可的信息。

OAuth2.0的四种授权模式

除了上述最常用的授权码模式，OAuth2.0 还定义了其他几种模式以适应不同场景：

• 授权码模式 (authorization-code)：适用于有后端的 Web 应用。通过前端传递授权码，后端换取令牌，令牌不暴露给浏览器，安全性最高。
• 隐式模式 (implicit)：适用于纯前端应用（如单页应用 SPA）。授权服务器直接将令牌通过前端重定向返回，省略了授权码步骤。令牌暴露在前端，安全性较低。
• 密码模式 (password)：适用于高度信任的客户端（如自家的移动端 App）。用户直接将用户名和密码交给客户端，由客户端用密码去换取令牌。风险很高，仅在对客户端完全信任时使用。
• 客户端凭证模式 (client credentials)：适用于没有用户参与的机器对机器通信（如微服务间调用）。客户端使用自己的身份标识和密钥直接获取一个用于访问受保护资源的令牌。

三、核心概念辨析：SSO、OAuth2.0 与相关技术

现在我们可以来清晰地梳理一下这几个关键名词的区别：

1. SSO：首先，SSO 是一种思想或解决方案，目标是解决用户在多个互相信任的系统间重复登录的问题。它是抽象的，我们需要按照其思想去实现，CAS 是实现之一。
2. OAuth2.0：其次，OAuth2.0 是一个标准的授权协议。它的核心目的是让用户能够安全地授权第三方应用访问自己在其他服务上的资源，它本身并非为单点登录设计。但是，我们可以巧妙地利用 OAuth2.0 协议来实现单点登录的功能。在这种场景下，被访问的“资源”就是用户的基本信息和权限，授权服务器负责令牌的发放与验证。
3. Spring Security / Shiro：最后，这两个是 Java 领域的安全框架，主要功能是访问控制，即在应用内部实现权限认证（Authentication）和授权（Authorization）。它们可以用来保护你的应用端点，决定“谁可以访问什么”。在实现一个基于 OAuth2.0 的 SSO 系统时，你可能会用 Spring Security OAuth2 来搭建授权服务器和资源服务器。

总结来说，你可以这样理解它们的关系：OAuth2.0 作为一种授权协议，可以作为实现 SSO 思想的一种技术手段；而 Spring Security 这类框架，则是在你的应用内部，对通过 OAuth2.0 获取到的用户身份进行具体的权限管理和访问控制，这涉及到复杂的 网络 与安全编程模型。对于希望深入探讨技术实现细节的开发者，欢迎在 云栈社区 的相关板块进行交流。