Should you build your own auth? Sometimes, yes.
Almost every developer writes a login form early on. That is a good way to learn, and we are not going to pretend otherwise to sell you something. What matters is knowing the moment the answer flips.
Write it yourself when
- A college project, a hackathon entry, or anything you are building to learn
- A side project with no real users yet
- An internal tool behind a VPN, where you are the only account
- A prototype you expect to throw away
- Anywhere the point is understanding how OAuth actually works
Keep your college project. You will understand tokens far better for having written the thing once.
Hand it over once
- Someone who is not you depends on getting back into their account
- You store anything you would not want to read about in the news
- A customer's security review asks how you handle session revocation
- You need SSO, SCIM, or an audit trail to close a deal
- An AI agent needs access to something on a user's behalf
At that point the cost of a mistake stops being yours and starts being someone else’s.
Your login form is 200 lines. The other 4,000 are the problem.
Email, password, a hash and a session cookie is genuinely a weekend. Here is what is waiting behind it, none of which looks urgent until the day it is.
Password reset that cannot be used to enumerate accounts
The naive version tells an attacker which email addresses are registered. The correct version behaves identically either way, which is harder than it sounds.
Refresh rotation with replay detection
A stolen refresh token used twice has to revoke the whole chain, not just fail once. Getting this wrong means a leaked token works forever.
Session revocation that actually reaches every device
Users expect “sign out everywhere” to mean it. Stateless JWTs make that genuinely difficult, and most hand-rolled versions quietly do not work.
Rate limiting that survives more than one server
An in-memory counter stops working the moment you run two containers. Credential stuffing finds that gap quickly.
MFA enrolment, recovery codes, and the lockout path
Adding TOTP takes an afternoon. Handling the person who lost their phone, without opening a social-engineering hole, takes considerably longer.
Export, deletion, and a trail that holds up
Under DPDP and GDPR a user can ask what you hold and demand you delete it. Both answers have to survive someone checking.
Industry estimates put passwordless and passkey support alone at 800+ engineering hours, spread across three to six months before it is ready for production. That is before anyone asks for SSO.
Buy the commodity. Own the product.
The useful question is not whether to build or buy. It is which half is actually yours. One half is a solved problem with public standards and no competitive value. The other half is your product, and you should never hand it to a vendor.
- Password hashing, and rehashing when the cost factor moves
- OAuth 2.1 and OpenID Connect flows, PKCE included
- Sessions, refresh rotation, and replay detection
- Passkeys, WebAuthn, TOTP, and email one-time codes
- Rate limiting and abuse controls
- Consent records, audit history, export and deletion
- Who is allowed to do what inside your product
- Your user model, profile fields, and onboarding flow
- How your accounts, teams, and workspaces are shaped
- Which plan unlocks which feature
- Everything that makes your product different from the next one
Read further before you decide
When the answer flips, this takes an afternoon.
Connect one application, register one callback, and run a real sign-in in a Test environment. Your users, sessions and audit trail come with it.