--- id: 42d64432-536c-3a1d-9a8c-9c5a040e135a title: 单点登录 SSO 方案设计 tags: '' publish_date: '2026-09-18 15:10:06' last_modify_date: '2026-09-18 18:18:16' sha256: 35f583f34a7aea92a24f84d60c92895dd0223e43b7cdc832e016bfc1076a4b4e --- # 单点登录 SSO 方案设计 ### 术语 1. 业务站点（客户端） 2. SSO 站点 3. SSO 服务 4. IDP 5. SP 6. S-Token 7. X-Token 8. OpenID：_Authentication，认证，_“你是你所声称的那个用户” 9. OAuth：_Authorization，授权，_“你能被允许做那些事情” 10. JWT：[JSON Web Token](https://link.jianshu.com?t=http://www.cnblogs.com/linianhui/p/oauth2-extensions-protocol-and-json-web-token.html#auto_id_6) ### 主要协议 1. OAuth2.0： - 与 OAuth 1.0 相比较 1. OAuth 2.0采用 HTTPS 代替 OAuth 1.0 流程所采用的大量密码学签名操作，保证数据完整性 2. 基于上述流程的简化，性能提升 3. 移动端应用支持，如原生应用唤起授权流程 - 授权模式 * 授权码模式（authorization-code） + 适用场景：最安全的模式，适用于有后端的 Web 应用或移动应用。 + 流程： - 用户访问客户端，客户端将用户重定向到授权服务器。 - 用户在授权服务器登录并授权。 - 授权服务器返回授权码（Authorization Code）给客户端。 - 客户端用授权码向授权服务器交换访问令牌（Access Token）。 - 授权服务器返回访问令牌和可选的刷新令牌。 + 示例：Google 登录：用户点击“用 Google 登录”后，网站后端通过授权码获取令牌，用于访问用户的基本信息。 ![](https://cdn.nlark.com/yuque/__puml/e3bd413f993f3d5469524673ffab0f89.svg) ```puml @startuml 'https://plantuml.com/sequence-diagram autonumber title 授权码模式（pkce,Authorization Code,无客户端后端服务） actor User as "用户" participant Frontend as "客户端前端\n(SPA/移动App)" participant AuthServer as "授权服务器" participant ResourceServer as "资源服务器" autonumber == 初始化请求（含PKCE） == User -> Frontend: 点击“登录” Frontend -> Frontend: 生成 code_verifier\n计算 code_challenge(S256) Frontend -> AuthServer: 重定向用户\nGET /authorize?response_type=code\n&client_id=123&state=XYZ...\n&code_challenge=abc...&method=S256 == 用户认证与授权 == AuthServer -> User: 显示登录页面\n(HTTPS) User -> AuthServer: 输入账号密码\n并授权 AuthServer -> AuthServer: 绑定\ncode, code_challenge, state == 授权码返回到客户端 == AuthServer -> Frontend: 重定向到 callback\nHTTP 302 Location: {redirect_uri}?code=ABC&state=XYZ Frontend -> Frontend: 验证 state\n匹配会话 == 令牌交换（关键安全步骤） == Frontend -> AuthServer: POST /token\ngrant_type=code&code=ABC\n&client_id=123&code_verifier=原始值\n&redirect_uri=... note over Frontend,AuthServer: 公共客户端流程\n不包含client_secret\n依赖PKCE保证安全 AuthServer -> AuthServer: 验证\n- code有效性\n- client_secret或code_verifier\n- 计算code_challenge匹配 AuthServer -> Frontend: 返回令牌JWT\n{access_token, refresh_token} == 资源访问 == Frontend -> Frontend: 返回用户会话\n(Set-Cookie或JWT) Frontend -> ResourceServer: GET /user\nAuthorization: Bearer {access_token} note over Frontend,ResourceServer: 需确保：\n1. 使用HTTPS\n2. 令牌短期有效\n3. 限制资源访问范围 ResourceServer -> Frontend: 返回用户数据 Frontend -> User: 显示登录成功 == 安全控制标注 == note right of AuthServer **公共客户端特殊要求**： 1. 禁止使用client_secret 2. 必须启用 PKCE 3. redirect_uri必须精确匹配 4. 令牌有效期应短于10分钟 end note @enduml ``` ![](https://cdn.nlark.com/yuque/__puml/3bde76a84e7a7fe4cc851b2f8fb7707a.svg) * 隐式模式（implicit） + 适用场景：纯前端应用（如单页应用 SPA），无后端参与。 + 流程： - 用户访问客户端，客户端将用户重定向到授权服务器。 - 用户在授权服务器登录并授权。 - 授权服务器通过 URL 片段（#）直接返回访问令牌（无授权码步骤）。 + 注意：令牌暴露在浏览器中，安全性较低。 + 示例：JavaScript 单页应用：一个天气预报 SPA 直接在前端获取令牌访问天气 API。 * 密码模式（password） + 适用场景：高度信任的客户端（如自家公司的移动端/桌面端应用）。 + 流程： - 用户直接向客户端提供用户名和密码。 - 客户端将凭据发送给授权服务器换取令牌。 + 风险：需完全信任客户端，因为用户密码会暴露给客户端。 + 示例：企业内部系统：公司自研的移动端 App 直接使用员工账号密码获取令牌。 * 客户端凭证模式（client credentials） + 适用场景：机器对机器（M2M）通信，无用户参与。 + 流程： - 客户端使用自己的 `client_id` 和 `client_secret` 向授权服务器请求令牌。 - 授权服务器验证后返回访问令牌。 + 示例：服务器间 API 调用：一个数据分析服务通过客户端凭证获取令牌，访问数据库 API。 2. OIDC：OpenID Connect，参考使用 Google、WeChat 等账号登录三方网站 - 报文格式：REST / JSON，JWT - OIDC=身份认证+OAuth 2.0，即 OIDC=认证+授权=Access-Token + ID-Token - OIDC 核心是在 OAuth2.0 授权（Access-Token）流程中同时提供用户身份认证信息（ID-Token）给第三方客户端，ID-Token 使用JWT格式来包装。得益于JWT 的自包含性，紧凑性以及防篡改机制，使得ID-Token可以安全的传递给第三方客户端程序并容易被验证。 - 应用场景：O系统，紫光档案系统，保融现金系统 - OIDC 术语： * **EU**：End User，用户 * **RP**：Relying Party ，用来代指OAuth2中的受信任的客户端，身份认证和授权信息的消费方 * **OP**：OpenID Provider，有能力提供EU身份认证的服务方（比如OAuth2中的授权服务），用来为RP提供EU的身份认证信息 * **ID-Token**：JWT格式的数据，包含EU身份认证的信息 * **UserInfo Endpoint**：用户信息接口（受OAuth2保护），当RP使用ID-Token访问时，返回授权用户的信息，此接口必须使用HTTPS 3. SAML：Security Assertion Markup Language - 报文格式：压缩和 Base64 编码 XML - SAML协议的核心是 IDP 和 SP 通过用户的浏览器重定向访问来实现交换数据 - 应用场景：JIRA、Confluence Wiki、阿里云 ### 基本需求 #### 用户需求 1. 单点登录 2. 单点登出 3. 支持跨域单点登录 4. 支持跨域单点登出 #### 安全需求 1. 防伪造 2. 防窃取 #### 互斥需求 1. 多会话：一个账号同时在多个设备/浏览器登录并正常使用 2. 会话互踢：一个账号同一时刻仅允许存在一个有效会话 #### 失效需求 1. 会话过期 2. 修改密码 #### 性能需求 ### 常见问题 1. cookies、session、token 的区别与联系 2. XSS 攻击、CSRF 攻击、Session ID 劫持 3. X-TOKEN 主动“外借”他人复用的解决方案 ### 参考资料 1. SSO单点登录的设计与实现 [https://zhuanlan.zhihu.com/p/196728329](https://zhuanlan.zhihu.com/p/196728329)