I Just Wanted a Login Form: A Dev's Auth Nightmare

You know that feeling when you just want to add a basic login to your side project? Username, password, done. Maybe throw in a "forgot password" link if you're feeling fancy.

Then you blink, and suddenly you're knee-deep in OAuth 2.0 RFCs, drawing OIDC flow diagrams at 2am, wrestling with SAML XML that looks like it was generated by a cursed enterprise wizard, and debugging OPA Rego policies that make regular expressions look readable.

Yeah. That's modern auth.

The Satire Site That Hits Too Hard

A security developer (who understandably requests no further auth questions) built I Just Wanted a Login Form to capture this exact nightmare. It's a React SPA that visualizes the absolutely unhinged requirements modern devs face when implementing "simple" authentication.

The site nails it with:

  • Social Login Hell: A wall of OAuth provider buttons. Not just Google and GitHub. Every. Single. Provider. Including ones you've never heard of and probably don't exist.
  • Password Policy Theatre: Validation rules so strict that "P@ssw0rd123!" gets rejected. Uppercase, lowercase, numbers, symbols, ancient Sumerian cuneiform, probably your firstborn's middle name.
  • Enterprise Feature Creep: SAML configuration panels, SSO integrations, and enterprise features that have absolutely zero business being in your indie hack project.

It's beautiful. It's terrible. It's too accurate.

Inspired by Database Satire

The project takes clear inspiration from YOU JUST NEED POSTGRES, which roasts database complexity. If that site is the antithesis to "DB complexity," this one is a primal scream about auth complexity.

Both sites hit the same nerve: the gap between what you actually need (a login form, a database) and what the modern ecosystem insists you must have (every auth protocol ever invented, seventeen different database paradigms).

The Reality of Modern Auth

Here's what actually happens when you "just add auth":

  1. Session vs Token: Do you use session-based authentication or JWT tokens? Plot twist: both have trade-offs that will haunt you.
  2. OAuth2 vs Everything: OAuth2 for social login, but wait, do you need OpenID Connect? What about SAML for enterprise? JWT tokens for APIs?
  3. Password Storage: bcrypt? Argon2? How many rounds? Did you salt it? Is your salt cryptographically random?
  4. Security Headers: CSP, CORS, SameSite cookies, HSTS. Each one a rabbit hole.
  5. Enterprise Requirements: Eventually someone asks about SSO, and suddenly you're learning SAML XML that looks like it escaped from 2004.

The CISA mobile security guidance alone could fill a book. OAuth2 JWT token examples sprawl across Stack Overflow. The debate between session-based authentication vs token-based authentication has more takes than a blockchain conference.

The Footer Says It All

"Made with frustration by a security developer. Please don't ask me about Auth."

This line captures the journey from "I'll just add a login" to "I now understand why Auth0 exists and costs what it costs."

Every engineer who's implemented authentication has been here. You start curious, maybe even interested in learning about OAuth2 vs SAML vs JWT. You end up with seventeen browser tabs open, comparing SAML vs OIDC specifications, trying to understand why enterprise SSO deployment requires a PhD.

Actually, Auth Is Pretty Cool Though

Plot twist: the developer admits that despite the complexity swamp, authentication and authorization are genuinely interesting. The depth is real. The learning curve is brutal. But there's something satisfying about finally understanding how these systems work.

Just don't expect it to be simple.

Try It Yourself

Next time someone in a meeting says "just add a simple login feature," send them this link. Consider it a public service announcement.

And if you're currently implementing auth: good luck, you're gonna need it. May your tokens be stateless and your sessions be secure.

T
Written by TheVibeish Editorial