OAuth for all

Original Article ↗ Hacker News Discussion ↗

Cloudflare is introducing OAuth-based delegated access to its infrastructure APIs, aiming to replace long‑lived API keys with more granular, revocable permissions and to open an ecosystem for third‑party tools. Commenters are split between seeing this as a sensible, overdue modernization that improves security and developer experience, and worrying about OAuth’s complexity, privacy implications, and the risks of giving third parties powerful access to critical infrastructure. The move also feeds into broader concerns about Cloudflare’s growing platform ambitions, potential vendor lock‑in, and the continued centralization of internet services.

Cloudflare’s direction and business model

  • Some worry Cloudflare is drifting from “simple infra + protection” toward a lock-in cloud platform, risking eventual cuts to free tiers once higher-margin services dominate.
  • Others argue free products are a core funnel and likely to remain, and that “cloud” is a natural extension of its original CDN/DDOS mission.
  • Concerns about centralization: Cloudflare is becoming a critical chokepoint for the web, which conflicts with a decentralized-Internet ideal.

OAuth for Cloudflare APIs: benefits and risks

  • Supporters see OAuth as safer than raw API keys: delegated access, scoped permissions, easier rotation, less key handling by users.
  • Skeptics highlight that for infrastructure accounts, delegating via OAuth to third-party tools can incur real costs and abuse if scopes are too broad or users misunderstand prompts.
  • Several point out that AWS and others already support similar delegated flows (via IAM/OIDC), though implementations can be confusing.

Complexity, usability, and “auth fatigue”

  • Many describe OAuth2/OIDC, IAM, and enterprise auth as over-engineered, confusing, and full of footguns, especially for simple server-to-server use cases.
  • Some argue the complexity comes from enterprise requirements and committee design, and that reading the specs plus using well-tested libraries makes it manageable.
  • A recurring desire: “just give me an API key” for personal or small-scale projects; fear that simple options will disappear.

Privacy and central identity concerns

  • Strong concern that OAuth providers can see where and when users log in, and could technically impersonate them or grant access to others.
  • Comparison with email-based signups: providers already see account creation, but OAuth adds precise login timing and centralizes more power.
  • Some advocate self-hosted or domain-based identity (IndieAuth, self-hosted OIDC) for better privacy, though adoption is low.

Ecosystem and alternatives

  • Discussion of other IAM/OAuth stacks: Ory (Hydra, Kratos, etc.), Keycloak, Supabase Auth, Zitadel, Authentik; tradeoffs in scale, complexity, and licensing.
  • Several emphasize OAuth is best when true user delegation is needed; for simple APIs, scoped keys with rotation and audit logs may be superior.

Cloudflare’s execution specifics

  • This feature is mainly about OAuth to access Cloudflare accounts, not generic “login with Cloudflare” for arbitrary apps.
  • Implementation is based on Ory Hydra; some technical curiosity about migrations and performance.
  • Broader criticism that Cloudflare often ships many products quickly but is slow to polish and complete basic features and tooling (e.g., wrangler gaps).