适用于所有人的 OAuth

原文 ↗ Hacker News 讨论 ↗

Cloudflare 的方向和商业模式

  • 有些人担心 Cloudflare 正从“简单基础设施 + 保护”转向一种会产生锁定效应的云平台，若更高利润率的服务占据主导，最终可能削减免费层。
  • 也有人认为，免费产品是其核心漏斗，并且很可能会继续保留；而“云”是其最初 CDN/DDOS 使命的自然延伸。
  • 对中心化的担忧：Cloudflare 正成为网络中的关键瓶颈，这与去中心化互联网的理想相冲突。

Cloudflare API 的 OAuth：优点与风险

  • 支持者认为 OAuth 比原始 API 密钥更安全：可委托访问、权限范围更细、轮换更容易、用户需要处理的密钥更少。
  • 怀疑者指出，对于基础设施账户，通过 OAuth 委托给第三方工具可能带来真实成本；如果权限范围过宽，或者用户误解提示信息，就可能被滥用。
  • 有几位指出，AWS 和其他公司已经支持类似的委托流程（通过 IAM/OIDC），尽管实现方式可能令人困惑。

复杂性、可用性与“认证疲劳”

  • 许多人认为 OAuth2/OIDC、IAM 和企业级认证过度设计、令人困惑，而且充满陷阱，尤其是在简单的服务器到服务器场景中。
  • 也有人认为，这种复杂性来自企业需求和委员会式设计；只要阅读规范并使用经过充分测试的库，就能将其控制在可管理范围内。
  • 一个反复出现的诉求是：对于个人或小规模项目，“直接给我一个 API 密钥”就好；担心简单选项会消失。

隐私与中心化身份担忧

  • 强烈担心 OAuth 提供方可以看到用户在何时何地登录，并且在技术上可以冒充他们或为他人授予访问权限。
  • 与基于电子邮件的注册相比：提供方本来就能看到账户创建，但 OAuth 增加了精确的登录时间，并让更多权力集中化。
  • 有些人主张使用自托管或基于域名的身份（IndieAuth、自托管 OIDC）以获得更好的隐私，但采用率很低。

生态系统与替代方案

  • 讨论了其他 IAM/OAuth 技术栈：Ory（Hydra、Kratos 等）、Keycloak、Supabase Auth、Zitadel、Authentik；它们在规模、复杂性和许可方面各有取舍。
  • 几位强调，OAuth 最适合真正需要用户委托的场景；对于简单 API，带范围控制的密钥配合轮换和审计日志可能更优。

Cloudflare 的执行细节

  • 这项功能主要是通过 OAuth 访问 Cloudflare 账户，而不是为任意应用提供通用的“使用 Cloudflare 登录”。
  • 实现基于 Ory Hydra；有人对迁移和性能表现出技术上的好奇。
  • 更广泛的批评是，Cloudflare 往往很快推出许多产品，但在打磨和完善基础功能及工具方面较慢，例如 wrangler 的缺口。