Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Three things to never build yourself: auth, notifications, payments

courier.com

Post reply on HN
Print view View original

111–120 of 193 posts

Re: Three things to never build yourself: auth, notifications, payments

#111

Post by outime »

mooreds wrote: post #81
rvense wrote: post #77

Earlier quoted context omitted.

I'm currently implementing Keycloak for my startup. It's not perfectly documented, but I really like all the things it can do for us and how extensible it is.

I'd suggest checking out FusionAuth, but I'm a bit biased :) . I have heard good and bad things about Keycloak, but I know one thing for sure: it's far better than rolling your own auth. Good luck with your startup!

I understand that you want to promote your solution and you have a disclaimer in the previous comment - and that's great. But if you keep insisting then you should IMHO at least provide some reasons on why your solution may be better than e.g. Keycloak and not just posting the name a couple times and see if it sticks.

Re: Three things to never build yourself: auth, notifications, payments

#112

Post by joncp »

rvense wrote: post #77
mooreds wrote: post #48

Earlier quoted context omitted.

You can also choose to self host. Keycloak and FusionAuth (disclosure, I am an employee) let you self host. You then have the user database in your systems. > And the only way off without a mass password reset is a silent migration in the background: migrate the user when they login.. but we all know that will take months and you will never get 100% to login during the migration period. Actually, not true. I can't sp…

I'm currently implementing Keycloak for my startup. It's not perfectly documented, but I really like all the things it can do for us and how extensible it is.

> not perfectly documented

Understatement of the year!

Re: Three things to never build yourself: auth, notifications, payments

#113

Post by nucleardog »

jchw wrote: post #38
capableweb wrote: post #18

More general: Things to never build yourself: Things outside your core business. Are you selling a notification service? Build it yourself, otherwise find either self-hosted or hosted solutions, depending on situation.

Sure, this is understandable wisdom. However, outsourcing has its risks too, as you need to trust who you are outsourcing to, often with your critical data, and your user’s data. Not only that, but you hard-depend on someone who does auth. Will these companies all be around in 5 years? Do they meet your security and compliance needs? etc. I know why people are against building custom solutions. I’m just gonna say tha…

I've had to have this discussion so many times.

Every one of these external dependencies is... a dependency. Each one brings with it the risk of the external company going under, prices rising to unacceptable levels, intermittent outages, etc. These are all independent events. For the sake of argument, if the risk of a company going under any given day is 1 in 100, then using five separate companies means our risk is 5 in 100 (1 in 20).

We need to weigh the risks plus impact against the advantages.

High risk + low impact or low risk + high impact are generally acceptable.

Auth is a space where generally it's moderate risk and high impact while the advantages are... quite low versus just throwing Keycloak onto your cluster and getting on with your day.

Re: Three things to never build yourself: auth, notifications, payments

#115

Post by sixhobbits »

mooreds wrote: post #48
rgbrenner wrote: post #27

Never outsource Auth. Maintain control over user accounts. That's the life blood of your business. If you have to ask everyone to reset their password because your auth provider increases their pricing or goes out of business, the churn will likely kill your company. I would say the same for Stripe, but at least they'll help you migrate off their platform. Auth providers cant help you because the passwords are hashed…

You can also choose to self host. Keycloak and FusionAuth (disclosure, I am an employee) let you self host. You then have the user database in your systems. > And the only way off without a mass password reset is a silent migration in the background: migrate the user when they login.. but we all know that will take months and you will never get 100% to login during the migration period. Actually, not true. I can't sp…

+1.

I maintained and extended a self rolled auth system built on top of django and it was a constant headache. We lost weeks of engineering productivity fighting with keeping the various libraries up to date and running into the usual "forgot password" edgecases.

I spent a few days with FusionAuth for a demo project and once I grokked it I really wished we had used it or something similar instead. Amazing abstraction layer to have at your disposal.

Re: Three things to never build yourself: auth, notifications, payments

#116

Post by jedberg »

sam_lowry_ wrote: post #82
remram wrote: post #66

Earlier quoted context omitted.

Making people reset their password is not that big of a deal. I have run into this multiple times, the most recent being amtrak.com. It just told me "you have to reset your password" and I got a link in email like if I had forgotten it. I have also received many "we had a security incident you have to reset your password now" emails in recent years.

There is a whole line of thought that accounts should be passwordless and accessed via an email reset link as part of normal login procedure.

Yeah I hate that method. It's good in theory but terrible for the user. I go to a website I want to use. I click the magic link. The email takes 10 seconds to show up. In that 10 seconds I find something else to do while I'm waiting. I get distracted and find the magic link in my email 10 minutes later. It's now expired and I have to start over. Or just give up.

With a password, I click the site I want to use, my password manager fills in the password for me, and I click "login" and bam, I'm done.

Re: Three things to never build yourself: auth, notifications, payments

#117

Post by void_mint »

arcbyte wrote: post #90
city41 wrote: post #62

Earlier quoted context omitted.

It's true the happy path and common error cases are easy to account for. But it just takes one overlooked bug or vulnerability either in your code or a library's code to send it all crashing down.

This is true across the board. One tiny crack in a bridge might mean it will collapse. That doesn't mean we should stop building bridges.

Sure, but it certainly means we should leave bridge building to those who are experts in that field.

Re: Three things to never build yourself: auth, notifications, payments

#118

Post by mooreds »

outime wrote: post #111
mooreds wrote: post #81

Earlier quoted context omitted.

I'd suggest checking out FusionAuth, but I'm a bit biased :) . I have heard good and bad things about Keycloak, but I know one thing for sure: it's far better than rolling your own auth. Good luck with your startup!

I understand that you want to promote your solution and you have a disclaimer in the previous comment - and that's great. But if you keep insisting then you should IMHO at least provide some reasons on why your solution may be better than e.g. Keycloak and not just posting the name a couple times and see if it sticks.

Fair point. Here's what I'd say if someone was choosing between Keycloak and FusionAuth:

I believe that FusionAuth has a better developer experience. Everything is an API, the docs are regularly updated (though we can always do better). There's an easy way to set up developer environments to a known state (Kickstart) that I don't believe Keycloak has an analog for.

FusionAuth supports limited memory environments. We have folks running in 384MB of memory. From what I've read, Keycloak wants more resources, though Keycloak X is apparently a good alternative. I don't know if Keycloak X has feature parity.

Theming is easier with FusionAuth, more typical auth flows can be themed, and themes can be entirely API managed: https://www.keycloak.org/docs/latest/server_development/#_th... vs https://fusionauth.io/docs/v1/tech/apis/themes/

If you want to run thousands of tenants,, FusionAuth is better. Compare https://keycloak.discourse.group/t/maximum-limit-of-realms/8... vs https://fusionauth.io/blog/2021/03/29/seegno-thousands-tenan...

Both options offer support (Keycloak via the Redhat SSO package), but you can view our pricing without talking to anyone. I wasn't able to find pricing for Redhat SSO (that's usually not a good sign, but maybe someone who has engaged with them can add more, I could be mistaken and it could be super affordable).

FusionAuth has a 100% free as in beer edition with unlimited enterprise or social connections, users, and tenants. (There are certain usage restrictions; you can't package FusionAuth and resell it without a paid license, for example.)

Keycloak has a large community and is 100% open source. Those are definitely strengths that I want to acknowledge.

It's always good to evaluate software as critical as auth (or payments or notifications, for that matter) with a POC simply because everyone's situation is a bit different and it does get embedded in your systems (source: I picked Stripe for a startup and evaluated moving off multiple times to save money but didn't end up doing so in part because of effort and opportunity cost).

Re: Three things to never build yourself: auth, notifications, payments

#119

Post by beardbandit »

deergomoo wrote: post #107
debaserab2 wrote: post #74

Earlier quoted context omitted.

This is literally the Auth0 first contact sales pitch designed precisely to scare you out of even trying to assess the risk of building it yourself. The reality is, though, it's never been easier than it is today to build secure auth - yes, it's still hard to do it right - but less hard than it ever has been before. So many security features are now a checkbox on a cloud provider's web interface that would have been…

Not to mention there’s a whole lot of middle ground between writing your own auth logic and using a hosted service. Any reasonably popular web-oriented language has plenty of fully featured, high quality libraries you can often just drop in. Hell, we use Laravel at work, which includes pretty robust auth features out of the box. It feels like such table stakes stuff for a web framework that I find the idea of paying…

I think that's where the confusion lies. Are people suggesting someone to write their own auth from the ground up, or write auth in coordination with their stack's auth library of choice?

Re: Three things to never build yourself: auth, notifications, payments

#120

Post by beachy »

mooreds wrote: post #81
rvense wrote: post #77

Earlier quoted context omitted.

I'm currently implementing Keycloak for my startup. It's not perfectly documented, but I really like all the things it can do for us and how extensible it is.

I'd suggest checking out FusionAuth, but I'm a bit biased :) . I have heard good and bad things about Keycloak, but I know one thing for sure: it's far better than rolling your own auth. Good luck with your startup!

I've never checked out your product, but we use Keycloak extensively and I can say it is a great Auth solution and I've used several and even built some (poorly).

The only real downside of Keycloak IMO is the documentation. Because it covers so many bases, and is very extensible, the official doc is enormous. There are a lot of lightweight articles about how to use it, I'd use one of those to get started.

Some great things about it are:

- it's widely used, so you can google your way out of most problems

- it does everything. When someone asks if you have 2FA or support Yubikey - the answer is yes.

- it's very extensible. Great APIs, and you also have access to the underlying database should you really need it (we never have, I'm sure some do).

- it's open source. IMO this is a non-negotiable for an auth system

Post reply on HN