Hacker News Reader

Comment by arcfour | Hacker News Reader

Ah, the SSO tax. We only care about security if you pay us, even if you implement it yourself.

> Ah, the SSO tax

For others that are not aware: https://sso.tax/

That's not why SSO is always in the enterprise version. It's not that the authors don't care about security, it's that only enterprises care about SSO.

That makes it a really good feature to withhold in order to force enterprises to pay, without significantly affecting individuals who want to use it.

(Standard HN disclaimer: when someone says "only this" or "everybody" or "nobody" in normal speech they don't mean literally nobody. You aren't proving me wrong by saying "ackshewally I use SSO and I'm not an enterprise".)

> only enterprises care about SSO.

Well that's just fundamentally not true any longer with OIDC. There are even simple OIDC auth plugins for reverse proxies now. It's what I consider a fairly basic feature in this day and age and it's a shame every time it's disregard as simply an enterprise feature

You might have an argument with saml, because it's a right pain, but not OIDC

I don't really follow. If you're setting this up for a couple of people you can just manually add accounts. It's probably even easier than setting up OIDC or whatever.

It's only when you get to enterprise level and IT departments want centralised accounts that it matters. They really need SSO.

Frankly I think it's a pretty great status quo. Consider the alternative, which is that the software would either not exist or be closed source.

If only enterprises need SSO, please tell me how I'd set up WebAuthn 2FA for these services without SSO.

Also, please explain how I'd change my password across this project, miniflux, seafile, postfix, dovecot, radicale, quassel, synapse and more all at the same time without SSO (in case the password got leaked)

So far, using keycloak and adding SSO support to these apps seems certainly like an easier option even for setups with 3-5 users such as my own.

Heck even in a single user environment like my homelab SSO is the simpler option.

You would do it manually. Not the end of the world if you have <10 accounts on all of those services.

For an enterprise with hundreds of users, that would mean thousands or tens of thousands of accounts to manage manually. Totally impossible.

It's a feature that's absolutely mandatory for enterprises, but "nice to have" for anyone else. That's why it's a great feature to use for price discrimination.

How do I manually setup WebAuthn 2FA with this project? Please give me a guide.

Because afaict, the only way to get proper 2FA with this project is by paying them for SSO.

SSO is not a requirement for secure software. It’s a requirement for enterprises because otherwise they have to manually keep track of everyone’s accounts everywhere, but that’s a management issue not a security issue (unless managed poorly).

Admittedly for many SaaS and OSS offerings SSO is an enterprise-only feature while it doesn’t have to be, but it’s the best discriminator they have to separate cheaper plans from enterprise plans. The alternative is to charge more for all plans, but then you lose out to the competition that does play this enterprise tax game.

For software to have secure authZ/authN, it should have robust 2FA mechanisms including WebAuthn, properly integrate with access tokens, and support scoped third party access.

Most software only offers simple username/password auth, or a paid SSO option as the only way to get 2FA working. And SSO makes it much easier to revoke access or change passwords if necessary.

I'm running hundreds of services self-hosted just for myself and less than a handful of close friends. I'm using SSO for all of them.

I had to patch SSO into countless services and I actively maintain forks with self-reimplemented enterprise features for almost half of them.

I had to do similar changes to get S3 support, as I use the AGPL version of Minio as storage backend for everything so I only have to setup backups in a single place.

The only reason one could try to argue that these are enterprise only features is if you assume personal users have no need for 2FA or backups.

Yeah, security features shouldn't be behind a paywall. I despise vendors that do it and do my best to avoid paying for products like that (and persuade my employer to do the same). You can say they have to make money somehow, but I don't care, not with this.

SSO isn't fundamental to most "open core" projects' security. So excluding from core seems like a reasonable compromise. They have to make money somehow. And IME the SSO implementations can be fidly and bespoke, so worth charging a premium to support.

It is, because even without looking at the product I can be very certain they don't implement nearly as good 2FA as say Keycloak or other solutions like that out there.

If anything, save some money and stop reimplementing all the login and account management functionality and let the OIDC (or worse, SAML) provider do it.

The problem is that login without SSO usually means even more fiddly and bespoke password and MFA implementations.

Can I paste in the password field? What and how many characters are allowed? Is it fed into a properly salted KDF? Can the password be intercepted by common logging/monitoring tools? How do I reset my password? Are there MFA options other than either SMS or TOTP? Can I have multiple MFA options active simultaneously, in case I lose access to one? Does an attacker having access to my email bypass all the other security measures? etc.

The support burden of doing that right has to be higher than that of doing SSO right. Of course, many won't prioritize hardening the open core security model until a large client suffers a breach, and a large client won't usually be using the open core anyway.

However, I actually agree with you about SSO implementations being too fiddly and bespoke, and moreover even doing OAuth2/OIDC the right way is tricky. Many/most guides online focus on using auth tokens to talk to first-party or tightly integrated APIs. Whereas, when using an OIDC provider for SSO, you actually just want proof-of-identity. Do I get an auth token and then call an identity endpoint? If so, do they support PKCE in the code flow? Do I get an ID token and then validate it? If so, do they support nonces in the flow? Which algorithms will be used to sign the token, and where do I get the keys? Even the major social-login providers don't all agree on the answers to these questions.

Reply on news.ycombinator.com