--- id: cd545eca-b994-44d9-95aa-2377aa71fc4b title: SSO(Single Sign-On) 方案设计 tags: SSO publish_date: '2026-03-16 09:17:41' last_modify_date: '2026-04-10 23:08:18' sha256: 882ec7b1ba63db8a3fb83dc61630fa635e11331b1a688c72cce85c9a4c37e044 --- ## 术语 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) ## 常用协议 ### OAuth2.0 #### 隐式模式（implicit） + 适用场景：纯前端应用（如单页应用 SPA），无后端参与。 + 流程： - 用户访问客户端，客户端将用户重定向到授权服务器。 - 用户在授权服务器登录并授权。 - 授权服务器通过 URL 片段（#）直接返回访问令牌（无授权码步骤）。 + 注意：令牌暴露在浏览器中，安全性较低。 + 示例：JavaScript 单页应用：一个天气预报 SPA 直接在前端获取令牌访问天气 API。 #### 密码模式（password） + 适用场景：高度信任的客户端（如自家公司的移动端/桌面端应用）。 + 流程： - 用户直接向客户端提供用户名和密码。 - 客户端将凭据发送给授权服务器换取令牌。 + 风险：需完全信任客户端，因为用户密码会暴露给客户端。 + 示例：企业内部系统：公司自研的移动端 App 直接使用员工账号密码获取令牌。 #### 客户端凭证模式（client credentials） + 适用场景：机器对机器（M2M）通信，无用户参与。 + 流程： - 客户端使用自己的 `client_id` 和 `client_secret` 向授权服务器请求令牌。 - 授权服务器验证后返回访问令牌。 + 示例：服务器间 API 调用：一个数据分析服务通过客户端凭证获取令牌，访问数据库 API。 #### 授权码模式（authorization-code） - 适用于有后端的 Web 应用或移动应用（最安全的模式） - 流程： - 用户访问客户端，客户端将用户重定向到授权服务器。 - 用户在授权服务器登录并授权。 - 授权服务器返回授权码（Authorization Code）给客户端。 - 客户端用授权码向授权服务器交换访问令牌（Access Token）。 - 授权服务器返回访问令牌和可选的刷新令牌。 - 示例：用户点击“用 Google 登录”后，网站后端通过授权码获取令牌，用于访问用户的基本信息。 ```puml @startuml 'https://plantuml.com/sequence-diagram autonumber title 授权码模式（client_secret,Authorization Code） actor User participant Frontend as "客户端前端" participant Backend as "客户端后端" participant AuthServer as "授权服务器" participant ResourceServer as "资源服务器" User -> Frontend: 点击“登录” Frontend -> Backend: 请求授权URL Backend -> Frontend: 返回授权URL Frontend -> AuthServer: 重定向用户请求到授权页面 AuthServer -> User: 显示登录/授权界面 User -> AuthServer: 输入账号密码并授权 AuthServer ->AuthServer: 验证用户身份 AuthServer -> Backend: 重定向到Callback URL (携带auth_code) Backend -> AuthServer: 用携带auth_code 交换 access-token (client_id+client_secret) note left: 1. auth_code 是临时的，短期有效 2. access-token 是长期有效的，通常是JWT note right: client_secret 是机密客户端方案，公共客户端建议使用 PKCE AuthServer -> Backend: 返回access_token Backend -> Frontend: 返回用户会话凭证 access-token Frontend -> Backend: 携带用户会话凭证 access-token 访问API Backend -> ResourceServer: 用 access_token 请求用户数据 ResourceServer -> Backend: 返回用户数据 Backend -> Frontend: 返回数据给前端 Frontend -> User: 显示登录成功界面 @enduml ``` ```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 "资源服务器" == 初始化请求（含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 ``` ### 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 ### 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)

Single Sign-On 方案设计