undefined | Better HN

0 pointspclmulqdq3y ago0 comments

I'm not entirely sure I agree with this - most auth providers are very expensive, and if you don't need the full-featured offering, you are way overpaying for the engineering time to build your replacement.

If you need all the features, it's a good deal, but you rarely do unless you are building something like Notion or Jira.

Open source components (Ory) can do the basic cryptography, and if you go completely from scratch, the NIST and their European counterparts have well-written standards for how to do this, and if you follow the relevant parts of the standard, you will get something essentially perfect without the baggage.

0 comments

mooreds3y ago

> most auth providers are very expensive

Some are, sure, but there are many that are not.

FusionAuth (again, I'm an employee) has a free community edition ( https://fusionauth.io/pricing?step=plan&hosting=self-hosting ) if you run it yourself with no limits on MAUs, SAML connections, tenants or users. Of course, we have plans that cost money because, hey, we all like to eat.

Auth0 has a basic plan that is free for 7k users. Mostly focuses on username and password, but is entirely adequate for getting started.

Ory (suggested elsewhere in the thread and by you) is OSS and free. Again, you have to operate it, which isn't free, but you get the benefits of upgrades and a team focused on auth.

Keycloak has a lot of features and is free if your run it yourself.

Supertokens has a basic plan that is free for 5k users.

There are many more, as well. And that is to say nothing of the OSS libraries (like devise/omniauth) which you can leverage.

Coding this from scratch seems like an enormous waste of time for something that is not typically a differentiator. At the least, use an OSS library or auth service and limit yourself to the features you need.

Customers pay for features, not for auth. Auth is just the front door to the application.

pclmulqdqOP3y ago

I think you're assuming that scratch coding is slower than integrating an OSS you don't know. When I was thinking about this for one project, it came close enough that I rolled my own basic auth system according to the NIST recommendations and it definitely took less time than integrating something that I didn't know (and accepting all the unknown bugs that are inevitably there).

I also don't buy the argument "don't waste time on something that is not a differentiator" - I'm going to spend time on it anyway, so I might as well spend the time in the most productive way possible. Also, I guarantee that your solution isn't bug-free, and eventually one of them is going to bite me, so that also factors into the decision about time.

The basic version of authentication is actually really simple. When you add SSO, RBAC, Oauth2, ACLs, and other stuff, it gets really complicated. People should make intelligent decisions about what they want to do here rather than just using a provider.

mooreds3y ago

> I think you're assuming that scratch coding is slower than integrating an OSS you don't know.

I think that depends on all kinds of factors (domain knowledge, docs of the library, etc). I think learning one or two auth libraries or frameworks will be useful to most devs, as they can re-use that knowledge repeatedly. But I get your point, sometimes rolling your own can be quicker. (And it is certainly more fun to code something up than to read up on integration docs.)

However, I think you're dismissing the long term maintainability advantages you get from using a focused library or auth server.

When a request comes in for a feature (let's change the hashing algorithm and factor of our passwords to meet new NIST standards, let's add login with LinkedIn, can we integrate using SAML), if you have the right library or auth server, it's often a configuration parameter, as opposed to code.

When there's a security issue, someone clearly owns it and has an incentive to fix it as fast as possible. Some auth servers (FusionAuth among them) pay people regularly to penetration test the system. Is that something you are going to do with your homegrown auth system?

That said, I'm glad you found a solution that works for you. Different strokes for different folks, as they say.

braveyellowtoad3y ago

Thanks for sharing. Do you know of any auth providers that charge based on auth event (login / logout / password change / etc) rather than per user?

mooreds3y ago

The big cloud providers have substantial free tiers (50k MAUs). Cognito, Firebase and Azure AD B2C all have a similar free tier. After you go through the free tier, you pay per MAU ($0.005 per MAU, according to https://aws.amazon.com/cognito/pricing/ , I think similar for the other providers. For smaller players, I think Stytch is 10c/MAU/month, where an MAU is any interaction with the Stytch service (login in all the many forms). https://stytch.com/pricing has more.

You'll have to dig a bit deeper into each pricing page to determine what actions make a user 'active'. I'm not aware of anyone who does MAU calculations on a day to day basis; monthly rollups are the standard.

Some folks charge per MAU (FusionAuth does) but in a band (the first 10k MAUs for a FusionAuth paid version are all one price).

HTH.

1 more reply

j / k navigate · click thread line to collapse

0 comments

mooreds3y ago

> most auth providers are very expensive

Some are, sure, but there are many that are not.

Auth0 has a basic plan that is free for 7k users. Mostly focuses on username and password, but is entirely adequate for getting started.

Ory (suggested elsewhere in the thread and by you) is OSS and free. Again, you have to operate it, which isn't free, but you get the benefits of upgrades and a team focused on auth.

Keycloak has a lot of features and is free if your run it yourself.

Supertokens has a basic plan that is free for 5k users.

There are many more, as well. And that is to say nothing of the OSS libraries (like devise/omniauth) which you can leverage.

Customers pay for features, not for auth. Auth is just the front door to the application.

pclmulqdqOP3y ago

mooreds3y ago

> I think you're assuming that scratch coding is slower than integrating an OSS you don't know.

However, I think you're dismissing the long term maintainability advantages you get from using a focused library or auth server.

That said, I'm glad you found a solution that works for you. Different strokes for different folks, as they say.

braveyellowtoad3y ago

Thanks for sharing. Do you know of any auth providers that charge based on auth event (login / logout / password change / etc) rather than per user?

mooreds3y ago

Some folks charge per MAU (FusionAuth does) but in a band (the first 10k MAUs for a FusionAuth paid version are all one price).

HTH.

1 more reply

j / k navigate · click thread line to collapse