Dear OAuth Providers

Original Article ↗ Hacker News Discussion ↗

Spec compliance and interoperability

  • Many commenters stress that OAuth/OIDC specs clearly define error formats and allowed error codes; providers that diverge (e.g., custom error strings, wrong types) break interoperability.
  • Others argue that in practice each provider behaves differently, making OAuth feel like a “skeleton” protocol where every integration is bespoke.
  • Some note that most problems described stem from providers ignoring, not misunderstanding, the spec. Others counter that if so many get it wrong, the spec may not be as “clear” as claimed.

UX issues: multiple providers and account confusion

  • Common frustration: users forget whether they signed up with email or which OAuth provider, accidentally creating duplicate accounts.
  • Workarounds: password manager notes (“OAuth: use Google”), services that auto-link by matching email, or offering explicit account-merging flows.
  • Several participants warn that auto-linking purely on email is dangerous; recommended best practice is to require existing credentials or extra verification before merging.

Security and trust in OAuth vs email

  • Debate over trusting emails from OAuth providers:
    • One side: never trust them, except possibly when the provider controls the domain (e.g., large webmail) and guarantees no reuse.
    • Others: even then, account compromise and weak verification flows make this fragile; but if password reset uses email anyway, additional risk may be marginal.
  • Some prefer plain email+password with password managers to avoid dependency, tracking, and lock-in to large identity providers.
  • Counterpoint: federated login brings strong MFA and verified identities, and empirically boosts sign-up conversion for businesses.

API design and HTTP semantics

  • Complaints about APIs returning HTTP 200 for errors instead of appropriate status codes; others argue this is a deliberate “HTTP as pure transport” philosophy.
  • OAuth RFC allows some leeway on HTTP codes, which may contribute to inconsistency.

Complexity and ecosystem problems

  • Commenters note dozens of OAuth-related RFCs and revisions; implementing “to spec” is hard, especially for smaller teams.
  • Integrators report that each provider (social networks, clouds, etc.) has unique quirks, often poorly documented, requiring per-provider special-case code.
  • Calls for official conformance test suites and certified libraries to reduce divergence and “roll-your-own” mistakes.

Provider-specific oddities

  • Examples include nonstandard token endpoints (separate refresh endpoint), string-encoded expiration times, Azure AD requiring client_id in scope, Discord not working with some OIDC clients, and AWS using ID tokens where access tokens are expected.