solo dev, ~400 registered users, currently email and password with a sessions table in postgres and an httpOnly cookie. every tutorial and every launch thread pushes an identity provider or oauth, and i keep wondering if i'm being negligent by not using one. is there a real technical reason to add oauth here beyond wanting google sign-in as a convenience?
I added google sign-in for a support reason, not a security one, and I'd do it again on that basis alone.
At about 700 users, password resets were 6 of every 10 support emails. Adding one social provider took a weekend and dropped that to almost nothing within two months, because the people who forget passwords are the same people who never had one with google. That's the actual argument: it removes a whole support category. It does not make your session handling safer, since you still issue a session afterwards exactly as you do now.
Matches my numbers almost exactly. Password resets were the single biggest support category until we added one provider, then they fell off a cliff within two months.
this is a much more convincing reason than anything i'd read. it's a support decision with an auth-shaped implementation, not a security upgrade.
First-party client, same site, session cookie. That's the design OAuth exists to avoid needing. Add social login when your support inbox asks for it, not when a tutorial does.
Slight disagreement with "you don't need it, move on." You don't need it today. You will need something on that road the first time a customer asks for SSO with their company directory, and that request arrives with a contract attached and a two-week deadline.
What I'd do at 400 users: keep passwords and sessions, but put your user lookup behind one module so identity source is swappable. Don't buy the identity provider now. Just don't wire user_id assumptions through forty files, because that's the part that hurts later, not the protocol.
this is the practical version of what i was actually asking. right now getUser() is imported in about thirty places but it does go through one file, so that's survivable.
That's the right shape. The rewrite that kills people is having the provider's user object leak into business logic — as long as your code only ever sees your own user row, swapping the front door later is a week, not a quarter.
The thing I got wrong writing my own was not the password hashing, which is one library call. It was the reset flow.
My reset tokens weren't single use, didn't expire for 24 hours, and were logged in plaintext by my email provider's webhook. Somebody with access to an old inbox could have reset an account any time that day. Nobody exploited it, I found it myself, and it still cost me a weekend and a very awkward changelog entry.
If you keep passwords, write the reset flow last, carefully, and test that a used token is dead.
@edge_runtime_bo · 3w ago
No, and the confusion is in the naming. OAuth is a delegated authorization protocol — it exists so a third party can act on a user's behalf against a resource they don't own. Your frontend is not a third party. It's the same application.
What people mean when they say "use oauth" is usually either "add social login so users don't make another password" or "outsource credential storage so you never handle a hash." Both are legitimate product reasons. Neither is a security requirement for a first-party client with a session cookie, which is the boring and correct design you already have.
Reply
Report