Cloudflare Access 为 Workers 提供默认访问保护
统一保护 Workers 应用
Cloudflare Access 现支持直接绑定到 Worker，也可以在账户层面为所有 Worker 设置默认访问策略。这样，内部应用无需依赖每位开发者单独配置，就能默认要求用户先通过企业身份验证。
可配置的保护范围包括：
- 账户级策略：让当前及未来创建的 Worker 默认受到保护，可覆盖预览流量、生产流量或两者。
- 单个 Worker 策略：为特定应用启用访问控制，并自动覆盖与该 Worker 关联的所有域名。
- 预览环境保护：所有新生成的预览地址都要求身份验证，包括 workers.dev 预览地址和用于预览的自定义域名。
- 全主机名保护：同时覆盖自定义域名、路由、workers.dev 子域名和预览地址。
如果某个 Worker 需要保持公开，可以对账户级策略设置例外。
认证在请求到达应用前执行
启用 Access 后，Cloudflare 会在请求到达 Worker 应用代码之前完成身份验证。请求通过哪种地址进入并不影响这一点：自定义域名、路由、workers.dev 子域名或预览地址都适用。
访问策略支持连接现有身份提供商，让员工使用已有企业账号登录，也可以按具体邮箱地址、邮箱域名或用户组限制访问。对于自动化代理，则可以使用服务令牌授予访问权限。
当同一应用存在多条策略时，优先级从高到低为：
- 主机名策略
- Worker 策略
- 账户策略
在代码中获取访问者身份
受 Access 保护的 Worker 可以通过请求上下文获取已认证用户的信息，包括邮箱、姓名和所属用户组。应用可以据此定制内容、执行权限控制或记录用户级活动。
身份信息通过 Worker 的 ctx.access 提供，可调用 ctx.access.getIdentity() 获取。开发者不再需要自行解析 JWT、验证签名并提取声明。
支持本地开发测试
开发者可以在使用 wrangler dev 本地开发时，在 wrangler.jsonc 中添加 Access 配置，以模拟已认证用户。Worker 通过 ctx.access.getIdentity() 获取与生产环境结构相近的身份对象，也可以修改配置中的邮箱来测试不同用户的访问效果。
用于构建默认私有的内部平台
对于支持员工原型开发和应用部署的内部平台，可以将 Access 策略配置在 Workers for Platforms 的调度 Worker 上。由于该命名空间中的流量都会经过同一个入口，每个通过调度 Worker 部署的应用都可以默认保持私有。
Cloudflare 还提供了一个开源内部站点平台示例：只需在调度 Worker 上配置一次访问控制，之后部署的站点便默认受到保护。
技术基础
这项能力基于 FL2 实现。FL2 是 Cloudflare 用于边缘网络的 Rust 模块化代理，采用严格的模块系统，将请求处理拆分为定义清晰、顺序一致的阶段，并静态声明各阶段的输入和输出。
为了让 Access 能够直接针对单个 Worker，而不只是主机名执行策略，系统需要先确定请求将路由到哪个 Worker，再进行访问控制。FL2 支持将 Workers 的路由与执行逻辑分离，并在访问控制阶段之前完成路由判断。
该功能现已可用，可在 Cloudflare 控制面板中尝试，或按照 Workers 的 Access 配置文档进行设置。