Comment by opportune | Hacker News Reader

Comment by opportune | Hacker News Reader

Parent Full thread

What’s insane to me is that it feels like nobody has actually managed to make this easy for developers yet. If they have, I don’t know about them.

I would normally consider myself pretty competent, but I stood up my first fully featured website recently with logins and such, and it took me about 2 days of work to get AWS Cognito working (using their recommended USER_SRP_AUTH). That’s not including 3rd party login functionality from Google and friends.

Their documentation and UX is piss-poor unless you’re willing to onboard your entire project to Amplify and enter npm-hell, which I wasn’t. It’s almost like they don’t even want your business.

I looked into using Auth0 instead and it didn’t seem to be any easier. Better docs, seems like they’re actually written by someone who both understands the auth problem domain and how to explain it to those that don’t, but still complex.

Yet when I was finished finally getting everything to work, it seems like the kind of thing you could easily package into an off-the-shelf product. It’s just that existing products don’t do it. Like why the fuck is there a guide explaining how to write a lambda to convert access codes to refresh tokens and persist them via cookies? That should be part of the Cognito platform!

Honestly thinking of just starting my own auth SAAS with blackjack and hookers

Don't judge the identity server space by Cognito, I beg of you. There are a lot of other players out there (I work for FusionAuth, one of them) who are working to make this easier.

Most have not been abandoned the way Cognito has. (Funny video on the topic: https://www.youtube.com/watch?v=x70EypnAH1Y .)

I don't know why Cognito hasn't seen more improvement. From the outside, it seems like CIAM would be worth investing in as a cloud provider. Say what you will about Azure and GCP, they both have CIAM platforms that see more love than Cognito (Azure AD B2C, Firebase).

> What’s insane to me is that it feels like nobody has actually managed to make this easy for developers yet. If they have, I don’t know about them.

There are definitely folks making it easier to add login/logout to applications (I see some of them pop up in sibling comments, and we are working on that at FusionAuth as well). But some of these are component libraries to proprietary SaaS applications. In this case you lose some of the power and standardization of OIDC. That works great for some use cases and not so good for others. The nice thing about OIDC is that almost everyone works with it (or with SAML). Certainly more than proprietary session based authentication providers.

I will tell you that as we are trying to make authentication simpler at FusionAuth, we have customers coming to us with pretty complicated use cases around federation, scale, automation, permissions and more. It's a balance to try to appeal to the developer who just wants authentication to work as well as the sophisticated customer who has these complex needs.

> It's a balance to try to appeal to the developer who just wants authentication to work as well as the sophisticated customer who has these complex needs.

This sounds like there should be two solutions, one for the simpler case and one for the complex case, rather than trying to make one solution work for all use cases.

My thoughts exactly. I want a simple auth solution that doesn’t push me towards a full batteries-included platform like Firebase and Amplify, nor a highly-configurable/complex “you can do everything auth!” platform. It’s ok if it’s a little opinionated, as long as it serves my use case of “adding logins and SSO to my website” up to 90% of the problem instead of 50% like what’s out there now.

It seems like an underserved market.

This is pretty much exactly what we built at WorkOS. (I work there.)

Check it out: https://workos.com/

And our Show HN launch a few years ago: https://news.ycombinator.com/item?id=22607402

I'd advocate that the right "simple" solution is a platform/framework specific auth solution (as I wrote here: https://news.ycombinator.com/item?id=38872704 ).

Those handle a lot of the simple use cases and some of the complex ones. They have the virtue of being well-tested and integrated with your development platform. You can deploy in one step and maintain one database. Which is great till it isn't.

What platform libraries like Devise, etc, don't offer is user data denormalization and isolation, which is useful when you have 2 or more applications with users. Then you want to look at auth servers (self-hosted or SaaS).

But you want the auth server experience to be as simple as possible, which is what we're working towards.

My two cents.

Have you tried WorkOS? (I work there.)

Makes it super easy to add SAML/SCIM to your app. https://workos.com/

We also recently launched https://www.authkit.com/

WorkOS looks interesting from a features perspective but license model based on number of connected organisations is so high it will mean most SMBs (my clients) can't afford it.

Our customers typically just bundle our pricing within their own team/enterprise plan and pass through the cost. IT admins even within SMB orgs are happy to pay a couple hundred dollars a month more for the enhanced security of SAML auth. And small teams realistically don't need SAML, so you can add a minimum requirement on the number of "seats" (assuming that's how you bill).

Fair points. But SAML doesn't cost much incrementally for each added customer org, yet it enables an SMB to simplify account lifecycle management. Important from a security perspective of course. Most SAAS do put it as an "enterprise" feature but it's a barrier to SMB security best practices.

A more complex yet rationale model would be a small incremental fee per user under the SAML.

I thought so too and we actually tried that first. After talking to about a hundred customers, I heard them resoundingly prefer per-org pricing because the flat cost is predictable within their own deal structure. I think the reason is that user counts can vary dramatically and b2b saas businesses are primarily driven/measured by the number of customers, not end users.

Not yet, I’ll give it a look next time I hack on my site. “Stripe for auth” is exactly what I’m looking for, and I know I still have a lot of auth head bashing left before I ship.

I’ll say though, my personal “customer demographic” ATM is more along the lines of someone who wants to get working user signups and auth and then never think about it again - so mentioning SAML/OIDC building blocks is a bit of a turn off for me. The reason is that I’m a solo dev trying to ship a browser-based multiplayer game, which I assign a low (maybe 5%) probability of ever becoming something with multiple people working on/turning into a real business - so I need auth, but would prefer to spend as much time as possible on the game itself, and don’t have anybody to farm the work out to.

But I’m happy to give workos a shot to see if it makes my life easier.

WorkOS is pretty tailored to folks building B2B apps where individuals will later be part of a team. (Think Dropbox, Figma, Asana, etc.)

It's less of a fit for B2C products where user identity won't ever be associated with a company (like ecommerce, a game, or a dating app).

The reason is that B2C apps actually have pretty different needs in terms of user identity. For example, most consumer apps will optimize for faster/higher conversion during signup and less security.

But if WorkOS works for your use case, then you should definitely use it. Our free tier includes 1,000,000 MAUs, which is significantly higher than Auth0/Clerk/Stytch/etc. which start charging you around 10,000.

Disclosure: I work for FusionAuth, an auth provider with a free community option.

If I were in your shoes I'd probably use a library built into whatever framework you are using. Auth servers are powerful but are another architectural component you have to manage (even if it is a SaaS, there's still config to manage).

Not sure what you are building it in, but if I were building it in rails, I'd use devise. If JS, maybe nextauth or passport.js.

When you do this you have to accept certain risks (what if your user data gets breached, what if you want to add more functionality) but based on the little you've shared, I think a local solution is perfectly fine.

I had a look at this recently and the pricing was pretty wild. Am I right in understanding that the connection charge is effectively per organisation?

Yes, per organization. SAML/SCIM have no user limits.

Hosted AuthKit is free up to 1,000,000 MAUs.

https://workos.com/pricing

How does AuthKit compared to Auth0? Any major differences?

Also what if you have an existing email-based account system which works fine - can you use AuthKit to add additional sign in methods like social without replacing your existing system?

The open-source nature of AuthKit is pretty different. You can build your own complete custom UI with the React components. Or build your own components from scratch and still use the WorkOS backend.

Outside of that, it's pretty much a drop-in replacement for Auth0. We also have more features, like native SCIM provisioning and a streaming events API to keep your app's database in sync.

> "I work there"

You don't just work there, aren't you the founder? :)

https://news.ycombinator.com/item?id=22607030

Yep!

I use Supabase just for auth (use AWS for everything else) and it was incredibly simple. The only issue is that their docs for my niche use-case were slightly out of date, but it still only took me maybe 30 minutes total.

Reply on news.ycombinator.com