Why building login from scratch is a bad idea
Login looks small until you add passwords, tokens, refresh, recovery, social login, audit, and security. Here is what that costs.
“It’s just a login endpoint” — every team has heard that in sprint zero. Two weeks later there is a refresh token, rate limiting, password hashing, MFA, email recovery, social login, lockout, privacy audit, and a session-fixation incident. Login looks simple because users only see a form. Underneath, it is a distributed security system.
What a “minimum” login hides
- Safe password storage (bcrypt/argon2, pepper, rotation)
- Issuing and revoking access and refresh tokens
- Protection against brute force, credential stuffing, and bots
- Password recovery that does not reveal whether an account exists
- Email verification and invite flows
- Social login with state, PKCE, and redirect validation
- Real logout (revoke the refresh token, invalidate the session)
- Audit logs and anomaly alerts
When does building it from scratch make sense?
Almost never for products with external users. Rare exceptions: extreme air-gap regulatory requirements, or when login is the company’s core business. For SaaS, fintech, healthtech, or any B2B API, the cost of a mistake exceeds the cost of an IAM platform.
Real risks
Security
- A JWT with no key rotation, or with the “none” algorithm
- A refresh token that lives too long, with no device binding
- Timing attacks in password comparison
Product
- Enterprise customers asking for SSO, SAML, or SCIM — and you do not have them
- Every new identity provider becomes a months-long project
- The core team stuck maintaining auth instead of the business feature
Classic mistakes of teams that “do it quickly”
- Storing the password in clear text or MD5
- A predictable session id, or a session that lives only in localStorage
- Reimplementing OAuth2 without reading the RFC — subtle redirect bugs
- Copying a 2019 Medium JWT tutorial
How Gatekeeper ID helps
Instead of maintaining an auth monolith, you consume login, refresh, registration, and social APIs that are already built — with multi-tenant, a console, and a Spring Boot SDK. Your team focuses on the domain; tokens, JWKS, and RBAC stay standardized.
The foundations are in OAuth2 vs OpenID Connect, JWT, explained, and social login in Java.
Conclusion
Custom login is technical debt with security interest. Use standards (OAuth2/OIDC), validate tokens correctly, and delegate what is not your differentiator — or budget for incidents and rewrites.