Hacker News Reader

Comment by gbro3n | Hacker News Reader

Not a decision I've got wrong, but I'd suggest authentication services are a common regret. Yes authentication is important to get right, but it's not _that_ complex. SaaS tools for auth are incredibly expensive for the feature set they offer, and are difficult to replace once embedded in your services. SSO in large scale business is a case where buy is the right option but I'd anticipate that for many simpler use cases teams have to work hard to unentangle themselves from Okta etc.

View on HN

I work at Stytch, a company that provides auth services

> Yes authentication is important to get right, but it's not _that_ complex...

Though I agree in some cases, I think that authentication complexity is rapidly changing and providing a _good_ authentication flow is not straightforward.

Consumer adoption of Passkeys, biometrics on mobile, OIDC/OAuth etc is really starting to take off and that really complicates your login flow quickly.

The eng time to get auth done right (and importantly securely) is not trivial, nor is maintenance. Even companies who's core competency is security get hacked (LastPass just this last week), it is that much harder to worry about when that isn't your core business.

> SSO in large scale business is a case where buy is the right option...

100% agree; any team that I've talked to wants solid, off the shelf SSO to add into their product within a sprint and doesn't want to embark on untangling the SAML/OIDC knot.

> ...teams have to work hard to unentangle themselves from Okta etc.

Agreed, a huge complaint that I hear all the time. Okta/Auth0 have decided to take the interesting road of increasing cost per user as you scale rather than offering volume discounts.

Whenever you're considering SaaS, it is critical that you look at cost per user over time and make sure your contract scales with you instead of explodes when you cross a threshold.

I'm looking forward to your SSO product. I hope that it adopts the same developer friendly pricing as your current product.

Authentication is a nightmare web of complexity to me that takes me away from the differentiators to my product that provide value. If I spend all that time and get it right, I might save $10 a month in a cloud bill. If I get it wrong, terrible, terrible things happen.

You can certainly pay $10 and still have terrible terrible things happen.

It’s hard to get right. In my experience plenty of developers fool themselves into thinking it’s not that hard. The problem is they’ve never read an NIST standard or spent time learning state of the art black hat techniques. If you don’t keep up you’ll implement something out dated or broken and not even know it.

Authentication is (usually) not that complex, but identity and authorization are. I've seen plenty of institutional regret when each application has its own pool of users and an internal authZ system.

Authorization is one of these areas that has traditionally been viewed as too hard to extract from the application, but it's core to no one's business and in recent years lots of companies have started to use authorization products. I'd chalk this up to:

1) Better abstractions for disentangling authorization

2) Better technical literature on the subject [1][2]

3) Increasing comfort with third-party infra services (RDS, LaunchDarkly, etc.)

Note: I'm cofounder of an authorization-as-a-service company (Oso) [3]

[1] https://www.osohq.com/academy

[2] https://research.google/pubs/pub48190/

[3] https://www.osohq.com/

I feel like authentication itself is probably straightforward, but there's a lot of boilerplate for account management that these services provide. Creating a new account, resetting a password, etc.

I'm thinking of firebase specifically. I'm using it for a website I'm building and I've spent very little time on integrating and using it. Quite less than it would take me to write the stuff myself.

(Note: I work for Passage.id, now part of 1Password...)

Auth is pretty easy to implement, but difficult to get and keep right. Then there are the nooks and crannies that crop up and appear and get discovered that you have to be aware of and keep up with. I am of course biased, but it seems to me that paying a company to keep up with the rapidly changing environment is much more efficient than trying to do it yourself.

And with WebAuthn and Passkeys -- you can implement that yourself without too much trouble. It's not trivial but not impossible, but the same argument applies -- nooks, crannies, corner cases, risks, etc.

I've spent a better part of last week upgrading Keycloak docker container from 13.0.1 to latest (and then rolling back the changes after I failed to make it work, I will try again after New year). IMHO, Redhat just introduces breaking changes on purpose to force you to pay for their single signon thing.

Installing and configuring it was relatively easy. Keeping it up to date and secure is a different thing

I agree, but only in a consumer environment, such as games and other trivial consumer apps with a lot of free sign-ups, when storing none or very little PII, where SSO/etc aren't ever going to be required. These SaaS products are far too expensive for free consumer apps.

Otherwise, if you are going to be selling into the enterprise and the majority of your users are paid, this is an area where using a SaaS tool is a no-brainer. Your sales team is going to run into customers that need XYZ-compliant auth and it's solved out of the box with the SaaS and cost isn't an issue since it'll just be baked into the per-user pricing.

I think auth SaaS is very expensive, but I’m currently playing with on-prem Zitadel, and it’s very good so far.

I twice worked at companies that built authentication as part of their application (using open source libraries, not from scratch). It's a mistake, and a mistake that's very expensive to fix later. Even more expensive not to fix given the sensitivity of this area of software.

All the companies I worked with in the last 15 years had custom auth (all bcrypt in the end).

Nothing bad ever happened. They're still rocking the same system and the only notable change that went through was adapting to gdpr deletion requests. And they all avoided that okta hack from some time ago.

What's expensive mistake are you talking about?

I thought I was alone on this one. I feel the same way.

We built our own elaborate auth system.

Soon afterwards keycloak came on the scene and negated a lot what we had done.

Shameless plug.

Our company (https://aembit.io/) solves auth problems (specifically identity and authentication between workloads).

I have been doing security and auth for the last 20 years in different shape and form. It's a minefield. Grabbing and using some SDK for auth is simple. Making sure that you account for the whole lifecycle (identity, authentication, authorization, secrets management, secrets rotation, addressing vulnerabilities as they pop up) is incredibly complex.

Reply on news.ycombinator.com