SSO 方案

news/2025/12/7 17:04:01/文章来源:https://www.cnblogs.com/zxlh1529/p/19166926

为多个域/子域、Web 与移动端，提供安全、可扩展、对外可接入的单点登录服务（SSO）。采用 OAuth2 Authorization Code + PKCE 与 OpenID Connect (OIDC) 标准，现在简单介绍一下：

核心概念

IdP（Identity Provider）：集中认证服务，负责用户认证、会话管理、签发 Token。
Client（Relying Party, RP）：各子系统/应用（如 main.example.com, learn.example.com），通过 OAuth2 与 IdP 交互。
Authorization Code Flow (with PKCE)：安全的授权码流程，适用于单页面应用与原生应用。
ID Token / Access Token / Refresh Token：ID Token（用户信息，JWT）、Access Token（授权 API）、Refresh Token（续期）。

高级流程（浏览器用户）

用户访问 main.example.com，未登录，点击登录。
main.example.com 重定向到 IdP 授权端点：

GET https://auth.example.com/authorize?client_id=web-client&response_type=code&scope=openid profile email&redirect_uri=https://main.example.com/auth/callback&state=xyz&code_challenge=abc&code_challenge_method=S256

IdP 完成身份验证（用户名/密码、第二因素等），在 IdP 建立会话（IdP 在其域下设置 HttpOnly, Secure 的会话 Cookie，例如 AUTH_SESSION）。
IdP 重定向回 redirect_uri，附带 code 与 state。
main.example.com 后端使用 code（和 PKCE verifier）向 IdP 的 /token 端点交换 access_token、id_token、refresh_token。此请求为后端到 IdP 的机密请求（client_secret 或 mTLS）。
IdP 返回 tokens。后端：
- 可将 refresh_token 写入HttpOnly，Secure，SameSite=None 的 Cookie（域为 IdP 或 client 依据架构）。
- Access Token 可放在后端 session 中或短期保存在 HttpOnly cookie。ID Token 用于获取用户信息。
main.example.com 创建自己的登录态（session / 本域 Cookie），用户在 learn.example.com 访问时依然保持已登录。

为什么 IdP 的会话能实现 SSO？

因为 IdP 在其域（如 auth.example.com）下为用户建立了“认证会话（AUTH_SESSION）”。当用户在另一个客户端（例如 learn.example.com）需要登录时，客户端会重定向到 IdP 的 /authorize：IdP 检测到已有 AUTH_SESSION，直接跳过凭证输入，完成授权并返回 code，从而实现无感单点登录。

关键端点

GET /authorize — 请求授权（浏览器重定向）
POST /token — 用授权码换取 token（后端到 IdP）
GET /userinfo — 使用 Access Token 获取用户信息
POST /revoke — 撤销 token（登出与安全处置）
GET /.well-known/openid-configuration — OIDC 元数据

登出（Single Logout）

前端触发：客户端调用 IdP 的 end_session 端点并传入 id_token_hint 与 post_logout_redirect_uri，IdP 清理自身会话 cookie 并可回调各客户端（后端或前端）以通知登出。
Back-Channel Logout：IdP 对各已注册的客户端发起服务端回调以通知登出。

注意：真正的全局登出在分布式系统中是有挑战的，建议结合短 token、revocation 与回调机制。

IdP 会话 Cookie（AUTH_SESSION）：Domain=auth.example.com 或 Domain=.example.com（取决部署），必须 HttpOnly; Secure; SameSite=None。
Refresh Token：放在 HttpOnly, Secure Cookie（如果是 Web 后端交换）或仅存在 IdP（对 SPA，放在 Authorization Code + PKCE 后端托管）。
Access Token：短期，尽量放在内存或后端，不直接写入可被 JS 访问的地方。
客户端登录态：客户端可选择使用自有 session（server-side session 或 signed cookie），并通过后端与 IdP 交互刷新/验证。

简要示例（Node.js）

1. 客户端重定向到 IdP `/authorize`

// 前端触发，后端生成 state & code_challenge
res.redirect(`https://auth.example.com/authorize?client_id=${CLIENT_ID}&response_type=code&redirect_uri=${REDIRECT_URI}&scope=openid%20profile&state=${state}&code_challenge=${challenge}&code_challenge_method=S256`);

2. IdP `/token`（简化示例）

app.post('/token', (req, res) => {const { code, code_verifier, redirect_uri, client_id } = req.body;// 验证 code、pkce；颁发 access_token, id_token, refresh_tokenres.json({ access_token, id_token, refresh_token, token_type: 'Bearer', expires_in: 3600 });
});

3. 客户端使用 Refresh Token（后端安全存储）

// 后端通过存储的 refresh_token 与 IdP 交换新 access_token
const r = await fetch('https://auth.example.com/token', {method: 'POST',body: new URLSearchParams({ grant_type: 'refresh_token', refresh_token }),headers: { 'Content-Type': 'application/x-www-form-urlencoded' }
});

安全推荐（实践要点）

优先使用 Authorization Code + PKCE（SPA/Native）。
所有 Token 端点仅通过 HTTPS 访问。
Refresh Token 使用 HttpOnly Cookie 或后端安全存储。
严格实现 CSRF 防护（state 参数）与重放保护（nonce）。
Token 限制作用域与最短有效期，并使用撤销（revocation）机制。
监控与异常检测（可疑登录、IP 变化、频繁刷新等）。

架构示意（ASCII）

User Browser│├─(1) /login --> Redirect to IdP /authorize│
IdP (auth.example.com)├─(2) Authenticate -> Set AUTH_SESSION cookie on IdP domain└─(3) Redirect back with code│
Client (main.example.com)├─(4) Server POST /token (code + verifier) -> receive tokens└─(5) Create client session (cookie) for appLater: another client (learn.example.com) redirects to IdP /authorize -> IdP sees AUTH_SESSION, issues code -> silent SSO