I too have seen the articles proclaiming that devs should stop implementing auth themselves and instead use some Auth as a service product. After all Authentication is hard to get right, right? Actually the basics are really easy. Using a short-term JWT and bcrypt to salt passwords is like maybe 10 lines of code. The thing is, most of the truly hard Auth problems I've had to solve in my career took a highly custom ap…
The identity federation protocol flows are pretty straight forward (I may be biased!) ... but you should use existing libraries for all the crypto. Defeating credential stuffing attacks is HARD. That is where services such as Auth0 shine.
Ask HN: What do you use to build auth?
121–130 of 141 posts
Re: Ask HN: What do you use to build auth?
#122Disclaimer: I am the co-founder of Cerbos[0] Auth is actually a combination of two things: authentication and authorization. Whatever you do, please do not build either by yourself. It always starts simple and it is guaranteed to get more complex than anyone is willing to maintain (unless you have a dedicated security engineering team) There are many providers for each. Authentication is about the user's identity and…
It's blanket statements like this that really make me rant on this subject. Lets mystify auth and tell devs to stay away from it! By the way, pay me to do it for you...
I mean by your own blanket advice, you should have never made the start-up that you did. There are no absolutes (well only for siths). Just tell people the pros and cons and what features you have. I work on apps in production, running for almost a decade, which we rolled our own auth on, and that have been maintained with a very basic level of tech-debt. I stand beside that work and guarantee it to our stake holders. What I cannot guarantee is X-company for the next ten years and if we will be able to migrate our data off their platform if they don't get funding.
Auth is not that hard. Policies are not that hard. Unix solved permissions 40+ years ago. I would argue, that if you are a small business use-case, you will probably never have to worry about these issues. If you are enterprise, you will have money to spend on it and be able to hire the talent and expertise. If you are somewhere in-between, then sure, go for some easy-use provider that gives you a form you can iframe or react component into your app or whatever. There is a market and use-case for cloud based services for user management, auth, policies, etc... I'd personally go with AWS cognito in this case, which I think is even a good cloud-native approach for enterprise. But please stop telling every dev to never build auth or policies by themselves just because you just recently did it and are now trying to monetize it.
Re: Ask HN: What do you use to build auth?
#123Earlier quoted context omitted.
Absolutely recommend against using AWS Cognito. It is a nightmare to use. Currently I am trying to integrate Firebase into AWS because of how bad Cognito is. One thing going well that Cognito will never be is Firebase Auth.
I wish it was easier to use Firebase Auth without the half-maintained javascript mess that is firebase-ui, which has not worked with the current Firebase SDK for, over a year now? (or at least I still failed transitioning from SDK 8 to SDK 9 as of a couple of months ago).
Re: Ask HN: What do you use to build auth?
#124I use firebase auth because it’s free at any scale and it takes minutes to set up. It’s backed by google so I’m not kept up at night.
Re: Ask HN: What do you use to build auth?
#125I am surprised that I did not find keycloak here…
For small projects, Keycloak is wayyyy too heavy for them. It requires multiple domains which makes sign outs hard... a OIDC server and client... it's a lot. It works well when you need to stitch together multiple services but otherwise it's not something I'd use for an MVP. (And even then you can wrap Auth with nested subdomains and a top level cookie w/ a proxy to pass headers to each service. Easier and less compl…
Re: Ask HN: What do you use to build auth?
#126I am surprised that I did not find keycloak here…
For small projects, Keycloak is wayyyy too heavy for them. It requires multiple domains which makes sign outs hard... a OIDC server and client... it's a lot. It works well when you need to stitch together multiple services but otherwise it's not something I'd use for an MVP. (And even then you can wrap Auth with nested subdomains and a top level cookie w/ a proxy to pass headers to each service. Easier and less compl…
Re: Ask HN: What do you use to build auth?
#127Re: Ask HN: What do you use to build auth?
#128Earlier quoted context omitted.
The only time I think it’s okay is with PKCE.
I mean, yeah, sure. Or for a number of other use-cases. I'd argue the best way is for the client to keep the token in memory over local storage. Of course if you have a tightly coupled app, session-based secure cookie is the best.
If there’s a use case to keep session tokens in localstorage, it’s insecure design that’s inherently vulnerable.
Re: Ask HN: What do you use to build auth?
#129Disclaimer: I am the co-founder of Cerbos[0] Auth is actually a combination of two things: authentication and authorization. Whatever you do, please do not build either by yourself. It always starts simple and it is guaranteed to get more complex than anyone is willing to maintain (unless you have a dedicated security engineering team) There are many providers for each. Authentication is about the user's identity and…
Auth is actually a combination of two things: authentication and authorization. Whatever you do, please do not build either by yourself. It's blanket statements like this that really make me rant on this subject. Lets mystify auth and tell devs to stay away from it! By the way, pay me to do it for you... I mean by your own blanket advice, you should have never made the start-up that you did. There are no absolutes (w…
* No one needs to pay
* No need for a company to be around for the next 100 years.Re: Ask HN: What do you use to build auth?
#130Earlier quoted context omitted.
Not implementing it yourself does not imply that you should use auth-as-a-service. There are plenty of auth libraries out there for your programming language of choice. Take a look at their source code and see how much stuff is in there to get a sense of why you should not implement your own. I use django-allauth: https://github.com/pennersr/django-allauth
Oh yeah, for sure, there are a really good libs. Someone mentioned passport. I've personally used Devise/warden in Rails. Though we had to monkey patch/extend it so much that 6 years later it was almost a different beast entirely. But I'd still argue it's worth knowing what those libs are doing for you and you can only really appreciate it once you've rolled your own. I've done so on many a personal project where the…