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

> doing your own auth implementations is somewhat risky

This is a false dichotomy: people can choose to use a framework that handles auth competently, such Django or Rails, no need to roll their own.

This is not to take away from your points (which I agree with), but for some reason I see many people thinking their only choices are signing their JWTs manually or using Okta.




> people can choose to use a framework that handles auth competently, such Django or Rails, no need to roll their own

The problem is there's a trend to prefer hyped-up languages with little/no battle-tested frameworks like those so this is literally not an option for a lot of companies where their "backend" is a pile of hand-rolled shit on top of Express.js, FastAPI or other minimalistic framework.

It might be a technically possible option to switch over to one of those, but too many people would have to lose face (at multiple levels, from individual developers all the way to investors) so it will never happen.


> This is a false dichotomy: people can choose to use a framework that handles auth competently, such Django or Rails, no need to roll their own.

If you want a centralized auth provider across different services, then something like Keycloak is indeed a good choice, which is why I mentioned it: https://www.keycloak.org/ Of course, for the actual services, you should go with a standard OIDC/OAuth2 library, or something like that, even a proven JWT library if need be.

Having Django or Rails (or one of the supporting libraries, like Devise) handle auth and permission control for more self-contained applications is also fine.

I'd just like to caution against writing your own badly documented and badly tested framework for auth, along the lines of storing unsalted MD5 password hashes, or even doing certain controls client side (although I haven't seen this personally, I've definitely seen lacking implementations and have heard stories from others in the industry).




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

Search: