通过Nginx实现多集群统一认证的关键是将认证能力上移至身份服务层，Nginx仅作为策略执行点，通过auth_request、JWT校验、Cookie域共享及OIDC集成等方式，实现认证集中化、会话同步与管理面SSO打通。
要通过 Nginx 实现多集群架构的统一认证接入，关键不是在每台 Nginx 上重复配置登录逻辑，而是把认证能力“上移”——让认证决策集中在统一的身份服务层，Nginx 仅作为策略执行点（Policy Enforcement Point, PEP），负责校验令牌、透传身份、转发请求。这种方式既避免了集群间认证逻辑分散，又支持横向扩展和故障隔离。
用反向代理 + 认证网关模式集中处理
Nginx 本身不内置 OIDC 或 SSO 登录页，但可作为轻量级认证代理，将未认证请求重定向至统一认证服务（如 Casdoor、Keycloak 或自建 Auth Server），再凭返回的 JWT/OAuth2 Token 验证后续请求。
- 所有业务集群（如 user-cluster、order-cluster）均通过独立 upstream 定义，不暴露原始后端地址
- 在 server 块中统一配置 auth_request 指令，指向本地认证验证接口（例如 /_auth），该接口由一个轻量认证服务（如 nginx-auth-sso 代理服务或 OpenResty Lua 脚本）提供
- 认证服务完成 OIDC Token 校验、用户信息解析、权限检查后，返回 200 或 401；Nginx 根据响应决定是否 proxy_pass 到对应集群
- 成功时，通过 auth_request_set 提取用户字段（如 $auth_user、$auth_email），注入 X-User-ID 等 Header 透传给后端
基于 JWT 的无状态会话校验
适用于已由上游认证中心签发标准 JWT 的场景，Nginx 可直接校验签名与有效期，无需每次回源。
- 使用 nginx-jwt 模块（需编译）或 OpenResty 的 lua-resty-jwt 库，在 access_by_lua_block 中完成解析与校验
- 验证 issuer、audience、exp，并比对 jwks_uri 公钥（支持自动轮转）
- 提取 claim 中的 sub、groups 或 roles，结合 map 指令映射为内部权限标识，用于 location 级别路由控制
- 注意：JWT 必须通过 HTTPS 传输，且建议配合 short-lived token + refresh 流程提升安全性
多集群共享会话上下文（Cookie/Token 同步）
当多个集群域名不同（如 cluster-a.example.com、cluster-b.example.com）但仍需单点登录体验时，需解决跨域凭证共享问题。
- 统一认证服务（如 Casdoor）设置主域 cookie：Domain=.example.com，Path=/，Secure+HttpOnly+SameSite=Lax
- 各集群 Nginx 配置中启用 proxy_cookie_domain ~\.example\.com .example.com，确保下游服务收到一致的 Cookie 域名
- 若集群部署在子路径（如 /a/、/b/），可用 proxy_cookie_path 重写路径，避免冲突
- 禁用各集群自身的 session 创建逻辑，全部依赖上游认证服务颁发的长期会话（如 Redis 存储的 session_id）
与 Nginx UI 集成实现管理面统一认证
若你同时使用 Nginx UI（或 NginxWebUI）管理多台 Nginx 服务器，其自身也支持 Casdoor/OIDC/WebAuthn 三种认证方式，可与业务面共用同一套身份源。
- 在 Nginx UI 配置文件中启用 [auth.oidc]，指向企业 Keycloak 或 Azure AD，使运维人员登录 UI 时即完成 SSO
- 确保 Nginx UI 实例与业务集群使用相同的 redirect_uri 域名前缀（如 https://admin.example.com 和 https://app.example.com），便于共享认证上下文
- 集群节点添加时，选择“OIDC Token 认证”而非密码，由 Nginx UI 自动携带有效 bearer token 连接各节点 API
- 这样，一次登录即可管理配置、查看日志、同步集群——管理面与业务面身份真正打通
