Dev Rant: Stop reinventing user auth

Whilst casually perusing bookshelf open issues (Shameless plug: my favorite node.js ORM, in-part because of its rich plugin ecosystem), I happened upon an issue that shall not be named. The question was simple…

Q: How do we set up a user signup/auth model with bookshelf?

Now, I could help this bloke along with a straight-forward knex schema connected to the canonical `bookshelf.Model.extend`, but then I thought…I’d be doing this poor chap a disservice. Why is he, and so many others like him, trying to re-solve this problem in the first place?

Usenet answer

Out of scope. Closed.

Short answer

If you have to ask that question, you shouldn’t. :-p

Medium answer

Seriously. Watch this video: Youtube: How NOT to Store Passwords!

Long answer

1. Use a fully-featured service and established 3rd party identity providers

For the vast majority of B2C apps, you and your users will be happier using an established identity provider (Openid, GitHub, Facebook, LinkedIn, Gmail, etc). For B2B, they’ll want SSO (Single-Sign-On). You can have multiple identify providers. The choice is largely a business decision.

On the tech-side, 3rd party providers like auth0 (industry leader, but there are about a dozen others) offer this as a service. Other services like Firebase do even more.

Basically, no real reason to do it yourself. All of the above feature nifty web consoles for user management and tons of other features that aren’t worth building yourself.

2. Do it yourself with a 3rd party identity provider

Passport-JS is the standard and supports all of the major providers. Optionally, you can choose to persist a straight-forward user / session table. No messing about with secure password storage, etc.

3. Do it yourself

Only if:

• Educational project / for the lulz

OR

• You know what you’re doing
• Have a compelling reason to not do (1) and (2), e.g. an on-premise requirement, highly regulated industry, etc.