1. 引言与核心分歧在设计现代微服务、前后端分离系统以及内部运维控制台如大模型可观测性看板时架构师面临的首要安全决策就是前后端之间的身份认证与鉴权流派。业界目前演进出了两大主流流派流派一网关级统一代理与 Cookie 穿透Gateway Forward-Auth / Token Exchange流派二前端持有 Token 与后端无状态验签Bearer JWT / OIDC PKCE很多团队在没有理清业务边界时盲目跟风引入复杂的前端 OIDC SDK 和 JWT 验签链条导致前端状态膨胀、跨域配置繁琐而在需要开放生态 API 时又受制于 Cookie 限制。本文将从工程底层原理、适用场景、边界限制以及如何利用 Cloudflare 边缘反代实现“虚拟同域”等方面对这两大流派进行全景拆解。2. 流派一网关级统一代理模式 (Kong Forward-Auth)2.1 工作原理与时序拓扑在网关级代理模式下前端和业务后端完全不参与复杂的 OAuth 授权码交换与 Token 刷新逻辑所有的身份拦截、校验和放行全部由集群边缘网关如 Kong Gateway OAuth2-Proxy在最外层终结。后端 API (/api/v1/logs)前端 SPA (/dashboard)OAuth2-Proxy LogtoKong GatewayCloudflare (Edge CDN)后端 API (/api/v1/logs)前端 SPA (/dashboard)OAuth2-Proxy LogtoKong GatewayCloudflare (Edge CDN)alt[未认证 (无 Cookie)]前端调用 API (同域自动带 Cookie)用户 (浏览器)访问 https://gw.jppwl.asia/dashboard1转发流量2触发 forward-auth 子请求 (/oauth2/auth)3302 重定向至 Logto 登录授权页4扫码/账号密码授权成功5写入根域 HttpOnly Cookie (Domain.jppwl.asia)6认证通过放行加载前端静态资源7GET /api/v1/logs8校验 Cookie 有效性9校验通过注入 Header: X-Auth-Request-User10转发请求 (携带清洗后的真实身份头)11返回业务数据12用户 (浏览器)2.2 核心优势前端代码“零鉴权”侵入React / Vue 前端不需要安装任何 OAuth SDK发请求直接用原生的fetch(/api/...)浏览器自动携带同域 Cookie完全省去了localStorage存 Token、防 XSS 攻击以及定时静默刷新 Token 的繁琐状态机。真正的全站无感单点登录SSOCookie 作用域设为根域名如Domain.jppwl.asia。只要用户在系统内的任一服务如 DbGate、MinIO登录过访问看板直接秒开。彻底消除跨域Zero CORS在同域名下通信不存在任何预检OPTIONS请求与Access-Control-Allow-Origin配置损耗。边缘绝对防御未认证的黑客流量在 Kong 网关最外层直接被拦截并重定向连后端的端口和代码逻辑都碰不到。3. 流派二前端持有 JWT 模式 (Bearer Token)3.1 工作原理与时序拓扑前端 SPA 单页面应用引入身份提供商IdP如 Logto / Auth0的 SDK走标准的 OAuth 2.0 PKCE 授权码流程获取 Access TokenJWT并在随后的每个 API 请求头中携带Authorization: Bearer Token。后端通过公钥JWKS对 JWT 签名、有效期及载荷进行本地无状态校验。业务后端 API统一认证中心 (Logto Cloud)前端应用 (logto/react)业务后端 API统一认证中心 (Logto Cloud)前端应用 (logto/react)前端将 Token 存入内存/SecureStorage后端拉取 IdP 公钥 (JWKS) 验签并解析 Payload用户 (浏览器 / App)打开应用1发起 OIDC 授权请求 (PKCE 流程)2返回 Access Token (JWT) Refresh Token3GET /api/v1/logs (Header: Bearer JWT)4验签成功返回数据5用户 (浏览器 / App)4. 深度对比既然流派一体验极佳为何流派二仍是全球公认标准如果网关 Forward-Auth 体验如此丝滑为什么各大公有云和开放平台依然以流派二为主因为流派一存在三大物理级限制而这些正是流派二的用武之地4.1 限制一Cookie 的同根域铁律跨域无法共享物理机制浏览器安全模型严格限制 Cookie绝不能跨根域写入或读取。例如Cookie 作用在.jppwl.asia如果前端托管在https://my-dashboard.vercel.app浏览器发请求时根本无法把 Cookie 发往不同的域名。流派二的表现JWT 只是一个标准的字符串存在 HTTP Request Header 里不受任何域名和同源策略的物理限制跨几百个完全不同的域名都能通用。4.2 限制二非浏览器客户端原生 App、小程序、CLI 脚本物理机制流派一严重依赖浏览器的 302 自动重定向机制与系统的 Cookie Jar 管理器。场景如果是 iOS/Android 原生客户端、微信小程序、或者是终端 Python/Go 自动化运维脚本它们不是完整的浏览器内核收到网关返回的 302 登录 HTML 时无法自然弹窗引导登录移动端系统没有天然的 Cookie 自动管理机制。流派二的表现原生 App 通过系统 Webview 拿到一次 JWT 后存入钥匙串Keychain之后的所有网络请求通过拦截器统一带上 Bearer Header架构极为标准化。4.3 限制三细粒度权限控制与微服务零信任调用Scopes Claims物理机制流派一通常只能传递“用户是谁User ID”网关放行代表“粗粒度信任”流派二的表现JWT 本身具备自包含载荷Self-contained Claims{sub:user_nvd11,scopes:[observability:read,metrics:export],tenant_id:hsbc_rcdp,exp:1788459999}后端微服务在拿到 Token 后无需查询数据库或鉴权中心直接解密即可判断该用户是否拥有特定操作的权限并且可以在微服务链路Service-to-Service中安全透传。5. 进阶技巧利用 Cloudflare 边缘反代打破“跨域限制”强行落地流派一很多时候前后端物理上部署在不同服务商例如前端托管在 Vercel / GitHub Pages后端部署在自建 K3s 集群。按照传统认知这必须使用流派二处理复杂的 CORS 和 Token。但借助Cloudflare 边缘统一入口Origin Rules / Worker 反代可以把物理上分离的跨域前后端在边缘层聚合成“逻辑上的绝对同域”从而无缝享受流派一的零前端代码与无感 SSO 红利统一入口路径: / 或 /assets/*路径: /api/*浏览器 (统一访问 https://dashboard.jppwl.asia)Cloudflare Edge 边缘统一调度前端托管 (Vercel / GitHub Pages)后端网关与服务 (K3s / OCI)落地配置示例Cloudflare Worker 边缘聚合exportdefault{asyncfetch(request){consturlnewURL(request.url);// 1. 如果是 API 数据接口无感路由到后端真实集群if(url.pathname.startsWith(/api/)){constbackendOriginhttps://k3s-gateway.jppwl.asia;consttargetUrlbackendOriginurl.pathnameurl.search;returnfetch(targetUrl,request);}// 2. 其余静态页面与资源请求无感路由到前端静态托管constfrontendOriginhttps://my-dashboard.vercel.app;consttargetUrlfrontendOriginurl.pathname;returnfetch(targetUrl,request);}};收益浏览器自始至终认为自己在和dashboard.jppwl.asia通信完美规避 CORS 跨域限制Cookie 自动传递前端保留纯净的静态页面特性后端完全被 Kong Logto 统一防护。6. 选型总结与决策矩阵场景与需求推荐选型核心考量私有运维看板 / 内部管理系统(如 LiteLLM 可观测性看板) 流派一 (Kong Forward-Auth)极简、零前端鉴权代码、全站无感 SSO、大厂内网最佳实践公网对外开放开放平台 / 第三方 API 生态 流派二 (Bearer JWT)跨域不受限、自包含 Scopes 权限控制原生移动端 App / 微信小程序 流派二 (Bearer JWT)脱离浏览器 Cookie 机制标准 OAuth PKCE 流程前后端物理分离但属于同一团队 流派一 Cloudflare 边缘同域利用边缘代理抹平物理域名差异享受零跨域与 Cookie 免密红利在我们的 LiteLLM Observatory 看板落地中坚定选用流派一Kong 网关统一代理作为主交互通道同时在后端兼容 Master Key 头部验证以支持自动化脚本达成开发效率与系统安全的最优平衡。