OAuth from First Principles
OAuth’s complexity makes it hard for developers to implement securely, but a widely praised “from first principles” explainer helps clarify why each step in the protocol exists and how it defends against concrete attacks. Commenters dive into practical challenges such as choosing between implicit and authorization code flows for static sites, where to store tokens safely in the browser, and how to think about threat models in real-world setups using services like AWS Cognito. The thread also surfaces broader trade-offs between rolling your own auth, relying on libraries, or using managed providers like Auth0 and newer open-source alternatives, with concerns about cost, vendor lock-in, performance, and long-term maintainability.
Overall reception of the article
- Widely praised as one of the clearest OAuth explanations, especially for building up the “why” of each step and attack.
- Several readers say they recently learned OAuth the hard way and would now use this article as their primary reference.
- Diagrams and Silicon Valley references are appreciated, though mobile rendering was initially broken and then fixed.
- Some note a missing mention of certain extensions (e.g., JARM, client secret usage in one attack).
OAuth flows, static sites, and token storage
- Long subthread on whether to abandon the implicit flow for static sites, especially with AWS Cognito.
- Concerns about sending refresh tokens to the client and storing them in
localStorage; some prefer short-lived access tokens without refresh. - Others argue modern best practice is code + PKCE; implicit is largely seen as legacy but sometimes the only option without a backend.
- Suggested mitigations: shorter token lifetimes, revocation, in-memory storage, HTTP-only same-site cookies (when a server exists), and DPoP for token binding.
- Consensus that the “right” answer depends on explicit threat modeling; static-site-only setups remain constrained and somewhat unsatisfactory.
Vendors, libraries, and build-vs-buy for auth
- Multiple commercial and open-source auth providers are mentioned as alternatives to Cognito/Auth0, with varying feature sets and pricing.
- Some report negative experiences with certain libraries (e.g., poor error handling, insecure defaults, unstable APIs).
- Advice for new SaaS:
- Early stage: use a managed SaaS or framework-native library to move fast.
- Long term / complex setups: consider dedicated identity servers or rolling your own on top of solid libraries.
- Watch pricing and vendor lock-in; auth is very “sticky.”
Security standards, banking, and redirects
- Readers point to OAuth Security BCP, FAPI, and banking integrations as important related material.
- Discussion of Plaid and banks: historically credential-sharing; now more OAuth but uneven adoption.
- Deep dive on redirect URI security: strict registration vs more flexible schemes using URL-based client IDs; concerns about open redirects and how PKCE mitigates some risks.
Performance, UX, and user behavior
- Some complain OAuth-based login flows are slow in real-world enterprise setups (multiple domains, heavy JS, global latency, extra MFA hops).
- Others counter that well-implemented flows can be nearly instant; disagreement centers on “in principle” vs “at scale.”
- Skepticism that typical users reliably verify domains; password managers and SSO are seen as partial mitigations.
Open source and business model debate
- Debate over whether “open source Auth0” positioning is genuine or marketing.
- One side emphasizes FOSS-first, “Supabase-style” hosting-and-support models; the other argues traditional VC expectations (exits) conflict with community trust in long-term openness.