---
URL: "/zh-CN/blog/2025-03/sso_key.html"
LLMS_URL: "/zh-CN/blog/2025-03/sso_key.md"
lastUpdated: true
commentabled: true
recommended: true
title: "单点登录：一把钥匙开启所有门"
description: "单点登录：一把钥匙开启所有门"
date:
pageClass: "blog-page-class"
---
---
lastUpdated: true
commentabled: true
recommended: true
title: 单点登录：一把钥匙开启所有门
description: 单点登录：一把钥匙开启所有门
date: 2025-03-07 10:00:00
pageClass: blog-page-class
---
# 单点登录：一把钥匙开启所有门 #
单点登录（SSO）技术，就像是一把开启企业数字化大门的钥匙，让用户一次登录，随处访问，极大地提升了工作效率和用户体验。具体到技术实现上，当用户首次登录时，SSO系统会进行认证，并发放一个凭证（如Token）。当用户尝试访问其他服务时，只需出示这个凭证，而无需再次输入账号密码。这不仅加快了工作流程，还大大减少了因记不住密码而导致的安全风险。
## SSO解决方案 ##
单点登录的核心在于：在多个应用系统中，用户只需进行一次登录认证，就可以无缝访问所有相互信任的应用系统。这背后需要一个独立的认证中心，通常称为Passport。
当用户首次尝试访问任一应用系统时，系统会将用户引导至Passport进行认证。一旦认证成功，Passport就会颁发一个令牌给用户。随后，用户携带这个令牌访问其他系统时，无需再次登录，系统会识别该令牌，并授予用户相应的访问权限。
这里会涉及同域名及不同域名两种方式：
- 同域名下的SSO：依托Cookie的域属性，可以实现同一个主域名下的各子域应用间共享token，从而实现单点登录。
- 跨域名的SSO：对于不同域的应用，可以通过建立一个独立的认证中心，使用令牌机制来实现单点登录。
下图就是针对跨域名的SSO的流程：
{data-zoomable}
在技术实现上，单点登录可以借助如 CAS（Central Authentication Service）、OAuth、OpenID Connect 等标准协议，也可以基于企业内部的自定义协议实现。在整个流程中，要维护一个全局认可的信任票证（token），并通过集中式的认证服务中心来进行身份的统一管理和验证。 **CAS（Central Authentication Service）和OAuth 2.0（Open Authorization）都是在网络应用中广泛使用的认证和授权协议。**
## OAuth 2.0 (Open Authorization) ##
OAuth 2.0是一个授权框架，允许第三方应用获取对用户资源的有限访问权限，而无需获取用户的凭证。OAuth 2.0更注重授权而非认证。
使用场景：OAuth 2.0广泛应用于互联网服务中，允许用户授权第三方应用访问他们存储在其他服务提供商上的信息，例如我们通过微信授权登录一个小程序或者应用。
工作流程：用户授权第三方应用访问自己在另一个服务上的资源时，该应用将获得一个访问令牌。该令牌允许第三方应用代表用户访问其资源。这个在微信开放平台、支付宝等都有相关接入说明及接口，大家可以去参考下。主要流程如下：
{data-zoomable}
1. 用户请求客户端应用程序访问资源。
2. 客户端应用向授权服务器请求授权。
3. 授权服务器要求用户提供认证。
4. 用户向授权服务器提供认证。
5. 如果认证成功，授权服务器将授权码发送给客户端应用。
6. 客户端应用使用授权码向授权服务器请求访问令牌。
7. 授权服务器向客户端应用发放访问令牌。
8. 客户端应用使用访问令牌向资源服务器请求资源。
9. 资源服务器向客户端应用提供资源。
10. 客户端应用将资源显示给用户。
## CAS (Central Authentication Service) ##
CAS是一种单点登录（SSO）协议，旨在允许用户在多个应用程序间使用单一的认证过程登录。它专注于解决用户认证问题，而不涉及授权。
使用场景：CAS通常用于单一组织或紧密相关组织的内部应用中，提供集中式的用户认证服务。
工作流程：用户首次尝试访问应用时被重定向到CAS服务器进行认证。一旦认证成功，用户就可以无需再次登录即可访问其他集成了CAS的应用。一般公司级的应用都会采用这种方式。
{data-zoomable}
### 用户未登录访问 app1 ###
1. 用户访问 app1 的受保护资源，app1 发现用户未登录，跳转至统一认证中心，并将自己的地址作为参数
2. sso 认证中心发现用户未登录，将用户引导至登录页面
3. 用户输入用户名密码提交登录
4. 统一认证中心校验用户信息，创建用户与 sso 认证中心之间的会话 TGC，同时创建 Token
5. 统一认证中心带着 Token 跳转最初 app1 的请求地址，浏览器缓存 TGC 及 Token
6. app1 拿到 Token，去统一认证中心校验 Token 是否有效
7. 统一认证中心校验 Token，返回有效
8. app1 使用该 token 创建与用户的会话，返回受保护资源
### 用户已登录 app1 再次访问 app1 ###
1. 请求携带 Token，app1 请求认证中心确认 Token 是否有效
2. app1 返回受保护资源
### 用户登录 app1 后访问 app2 ###
1. 用户访问系统 2 的受保护资源，未携带 app2 的 Token
2. app2 发现用户未登录，跳转至统一认证中心登录页，并将自己的地址作为参数
3. 登录页拿到 TGC，判断已经登录，跳转到 app2 页面
4. 请求统一认证中心通过 TGC 换取 Token
5. 统一认证中心校验后，返回 Token
6. app2 使用该 Token 创建与用户的局部会话，返回受保护资源
## 总结 ##
通过实施SSO，企业可以极大地简化用户的登录流程，加强数据安全，提高工作效率。无论是采用CAS还是OAuth 2.0，关键在于选择最适合企业自身需求和现有架构的解决方案。