2026-04-19 学习日志

今日主题

Cloudflare Workers 项目结构
Cloudflare DNS 代理机制
DNS 域名委派与 Glue Record
Authing 身份基础设施与微服务集成
身份协议：SAML、OIDC、OAuth、CAS 的关系
Authing 身份基础设施与微服务透传
联邦认证原理
DNS 控制面与数据面分离

新增认知

Cloudflare Workers 项目结构

worker-configuration.d.ts 是由 wrangler types 自动生成的 TypeScript 类型声明文件，声明 Workers 运行时全局类型（如 DOMException）和 Env 接口（KV/D1/R2 等绑定），不应手动修改。
tsconfig.json 在 Cloudflare Workers 项目中主要服务于 IDE 补全和类型检查，实际编译由 Wrangler 负责，而非 tsc。
tsconfig.json 支持注释的原因是 TypeScript 将其以 JSONC（JSON with Comments）格式解析，这是 TypeScript 对该文件的特殊处理，并非标准 JSON。
tsconfig.json 不应改名为 tsconfig.jsonc：tsc、VSCode、ESLint 等工具默认只识别 tsconfig.json 这个文件名，改名会导致自动发现失效。

Cloudflare DNS 代理机制

橙色云 vs 灰色云：橙色云让流量经过 CF 反代（CDN + 隐藏真实 IP），灰色云只做 DNS 解析、流量直连服务器。
Worker 类型记录无法关闭代理：Worker 代码本身运行在 CF 边缘节点，流量必须经过 CF，架构上无法绕开。
Secondary DNS Override 的本质区别：普通 CF（Primary）中 CF 是 DNS 记录的主控方；Secondary DNS Override 中记录主控权留在自己的 DNS（如 AWS Route 53），CF 只做同步和代理，NS 虽然都指向 CF，但记录编辑权不同。
CF DNS 面板中带锁图标的记录有两种情况：一是 CF 自动配置的邮件路由记录（MX/TXT），防止误操作；二是 Worker 绑定记录，必须代理。

DNS 域名委派与 Glue Record

修改 NS 记录不是移交域名，只是将 DNS 解析控制权委托给其他 DNS 服务商；域名注册权仍在原所有人手中。
子域名委派（Subdomain Delegation）：在父域名区域文件中为子域名添加 NS 记录，可将该子域名下所有记录的解析权独立委托给其他 DNS 服务器管理。
Glue Record 解决循环依赖：当委托的 NS 服务器本身在被委托的子域名下（如 ns1.sub.example.com），解析器无法先查到 NS 的 IP。Glue Record 是在父域名区域文件中直接附上该 NS 服务器的 A 记录，让解析器绕过循环。
实践上：委托给第三方 NS（如 Cloudflare）不需要 Glue Record；只有自建 NS 且 NS 域名位于被委托子域名下时才需要。

Authing 身份基础设施与微服务集成

ID Token 与 Access Token 职责严格分离：ID Token 是身份凭证（证明你是谁），Access Token 是授权凭证（证明你能干什么）。绝对不能用 Access Token 做用户认证，也不应用 ID Token 做 API 鉴权。
JWT 本地验证（RS256 + JWKS 公钥缓存）是微服务鉴权的推荐方案：无网络依赖、可横向扩展、毫秒级验证。在线 Introspection 的唯一优势是可检测 Token 是否被撤销，但引入了网络延迟和单点故障风险。两者结合使用：平时本地验证，logout/安全敏感场景走在线验证。
微服务身份信息透传的标准模式：API Gateway 统一验证 JWT → 解析 sub/scope/claims → 转换为内部信任 Header（X-User-Id、X-User-Roles 等）→ 下游微服务直接读 Header 不重复验证。安全前提是 Gateway 剥离原始 Authorization Header，内网有网络隔离（NetworkPolicy / mTLS）。
RBAC 是静态角色映射，简单但无法做细粒度资源控制；ABAC 基于用户属性+资源属性+环境属性动态计算，能表达复杂场景（如「只有文档所有者且文档是草稿状态才能编辑」），但每次权限判断需远程调用 Authing 策略引擎，生产环境需配合短 TTL 本地缓存。
Authing 的本质是把 IAM（认证、授权、用户生命周期）从业务代码中剥离出来，以托管 SaaS 形式对外暴露标准 OIDC/OAuth2 协议接口。集成侧只需理解协议语义，不需要自建用户系统、密码管理、MFA、SSO 等基础设施。

身份协议：SAML、OIDC、OAuth、CAS 的关系

OAuth 2.0 本身解决授权，不直接等于登录；现代应用里常说的‘OAuth 登录’，更准确通常是 OAuth 2.0 + OIDC。
OIDC 的核心价值是在 OAuth 2.0 之上补齐身份认证层，用 ID Token 标准化‘用户是谁’这件事；登录看 ID Token，访问 API 看 Access Token。
SAML 的浏览器回传并不是 IdP 直接把结果推给 SP，而是 IdP 返回一个包含 SAMLResponse 的自动提交 form 页面，由浏览器再 POST 到 SP 的 ACS 接口。
SAML 场景里通常不会遇到前后端常说的 CORS 问题，因为它依赖的是浏览器顶层跳转和原生 form 提交，而不是 fetch/XHR 跨域读响应。
现代系统继续支持 SAML，主要不是因为 SAML 更先进，而是因为企业身份基础设施、审计流程和存量集成长期围绕 SAML 建立，兼容成本比协议优雅更重要。

Authing 身份基础设施与微服务透传

Authing 的核心不是提供一个登录页，而是把用户目录、应用接入、认证、授权、联邦、会话与审计统一成身份控制平面。
从工程选型看，OAuth 2.0 更偏资源授权框架，OIDC 才补齐了标准化身份断言；面向 Web、SPA 和多系统单点登录时，能选 OIDC 就优先 OIDC。
既有技术资产集成时，Authing 最有价值的角色通常不是直接替换所有上游身份源，而是作为联邦中枢或身份代理，把 AD、LDAP、Azure AD、自研 SSO 等上游统一编排后再向下游应用输出标准协议。
身份、权限、用户信息透传到微服务时，最稳的链路是：边界层校验外部 access token，提取统一身份上下文，再以内部可信上下文或内部重签 token 在服务间传播，而不是让内部服务直接信任前端自带 header。
Token 里适合放稳定、低频变化、跨系统通用的身份断言，如 sub、tenant、org、roles、external_id；高频变化的业务权限不应塞进 token，而应在业务服务或授权服务实时判断。

联邦认证原理

联邦认证的本质：两个原本独立的身份系统，通过协议约定建立信任关系，用户在 IdP（身份提供商）认证一次，SP（服务提供商）凭「身份断言」放行，双方数据库保持独立、互不统属。「联邦」强调的是独立性，而不是合并。
「身份断言」是联邦认证的核心传递单元：IdP 签名背书的声明，内含用户标识、属性、有效期、指定受众（SP）。SP 收到后只需验签（防伪造）+ 提取用户信息，无需重新认证用户。不同协议的断言格式：OIDC→JWT ID Token，SAML2→XML 文档，OAuth2→Access Token + userinfo 端点，CAS→XML ticket。
Authing 作为联邦中枢，可同时扮演两个角色：对上游（企业微信、GitHub、LDAP/AD 等）是 SP，信任并消费这些 IdP 的断言；对下游业务系统是 IdP，统一签发断言。业务系统只需对接 Authing 一次，上游身份源变化对下游完全透明。

DNS 控制面与数据面分离

DNS 的控制面/编辑面与数据面/解析面分离，本质是把唯一可写的 zone 配置源和对外高性能回答查询的权威服务拆成两个系统，中间靠 AXFR/IXFR/NOTIFY 把状态复制成只读服务快照。
Cloudflare 的橙云不是新的 DNS 记录类型，而是 Proxied 代理状态：DNS 返回 Cloudflare 的 Anycast IP，后续 HTTP/HTTPS 流量先进入 Cloudflare，再由 Cloudflare 回源。
当 Cloudflare 作为 secondary 且要提供橙云能力时，关键不是修改主 DNS 原始记录，而是在 secondary 副本之上叠加本地 override 元数据，再把主 zone 与 override 合并成最终对外回答的记录集。
AXFR、IXFR、NOTIFY 属于 IETF 的中立标准协议，secondary 不能单方面接入；前提是主 DNS 必须支持区传、允许访问、通常还需要 TSIG 与 ACL 配置。
从商业逻辑看，主 DNS 是否愿意支持这种分离，取决于它卖的是配置治理能力，还是配置治理加公网权威解析和安全流量入口的整包价值；hidden primary 方案实际上让主 DNS 留在控制面，把数据面价值让给 Cloudflare。