Comment by solatic | Hacker News Reader

Comment by solatic | Hacker News Reader

Parent Full thread

> That is why a very technically solid person is gold in the first round, because they can design the signup in such a way that it's prepared for future requirements. They of course would also know that you can't store in plain text, that it should be hashed, that you might have to use a vault, that you need to randomize the hash, and that in the future limit access to the "user" table and never ever expose it through an endpoint where a user can reach it, as well as protecting against XSS and SQL injections.

Wrong. The correct technical decision is to bundle in a library that solves this for you - login with Google, or Facebook, or GitHub, or OIDC, pick one according to the context. Get password reset, MFA, password security, etc. for free.

Why reinvent the wheel, poorly?

The thing is, that's not just a technical decision. There are strategy, product, and operational reasons why you might decide to add or avoid SSO. SSO for sign-on can be really complicated and have lots of caveats -- for example, Apple requires any app with any SSO option to also support sign in with Apple, or be removed from the app store. Or you may want to restrict certain SSO to enterprise customers only, as a feature, but not have any of them yet. Or your users might have privacy concerns about SSO, or not have accounts at your SSO providers.

Any of these things may or may not be relevant to your decision, and I know that authentication is a specific example within a larger point. What I'm trying to say is that it's never correct to say "<x> is the right approach for all <y> trying to do <z>". Every decision has consequences, and what really matters is your ability to foresee those consequences and weigh them against the broader strategic picture of what you're trying to accomplish.

I think this was an example based on the op example.

Assuming that Google or Facebook or Github has implemented a library correctly, and that it will remain available as long as you want your app to function is dangerous.

As opposed to assuming that you'll implement it correctly when Google or Facebook or github haven't?

Yes, because what's good for them is not necessarily what's good for you.

Reply on news.ycombinator.com