Whilst casually perusing open issues (Shameless plug: my favorite node.js , in-part because of its ), I happened upon an issue that shall not be named. The question was simple… bookshelf ORM rich plugin ecosystem 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 (industry leader, but there are about a ) offer this as a service. Other services like do even more. auth0 dozen others Firebase 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 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. Passport-JS 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.