为多个域/子域、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 与回调机制。
Cookie 与 Token 存放建议
- 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
何时使用？
- 需要对外开放登录（第三方应用、合作伙伴）。
- 跨多个主域、移动端、微服务环境。
- 需要遵循安全合规、审计、可扩展的身份管理方案。
So：标准化 SSO（OAuth2/OIDC）是面向长期、跨平台、跨组织场景的推荐方案。对于仅限同一主域内部子域的快速场景，集中 Session 模型是比较轻量且实用的选择，或者看之前文章介绍的类 SSO 哦~。