Hacker News new | past | comments | ask | show | jobs | submit login

When it comes to Authentication and Authorization, these are both core components of a system but undifferentiated building blocks so wouldn’t recommend building them yourself.

Typically using something like Auth0, Cognito, Firebase Auth, FusionAuth, Clerk or many of the other authentication services will get you a full feature set for user management with little to no work.

On the authorization front consider a similar approach of decoupling the the component out of your codebase where the permissions logic is defined as policy rather than code. I work on Cerbos[1] which is an open-source, decoupled authorization layer for your software which does exactly this.

[1] https://cerbos.dev




I could not disagree more — allowing a third party to own the most crucial data in your app (the users) is a big mistake. I’ll admit to only having experience with Firebase for third-party auth, but in my experience the drawbacks of splitting auth and user related code between two systems soon outweighs the benefits of getting up and running quickly.

Auth code is undifferentiated, but if you have experience building apps it’s also not particularly difficult. I’d recommend either picking an open source solution that you host yourself or just taking a few days to grind it out.


I want to disagree with both of you - the sweet spot is often 3rd-party authN, 1st-party authZ:

* don’t try to implement the hard/annoying bits (strange access detection, account recovery, sending emails, password storage)

* keep ownership of your user list and users’ capabilities


I disagree with all three of you.

It depends on the use case.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: