As others are pointing out, once you've grown big enough that you can't trust everyone with the keys go the kingdom: enterprise pricing is for you.
SSO Tax is a fun meme, but it misses the point: Whether it's 5 people or even 3, you've scaled your business enough to hire people who aren't in the inner circle.
That's a fair place to consider you an enterprise.
Not sure what you're talking about. It's not like without SSO everyone in the company has to all use the same password. Services allow people to have separate users with separate privileges.
It sounds like you're unaware of why SSO is considered a security feature at all them, but it's covered right on the site: https://sso.tax/
It's to allow centralized access management. Stuff like firing someone and revoking their access from one platform instantly, instead running around and changing permissions in every tool manually. Or ensuring people in department A can't be invited to some platform for people in department B in order to limit information access.
SSO tax is predicated on the idea that the moment you outgrow the informal arrangements and liberal access, you're really a business. Seems pretty fair?
> It sounds like you're unaware of why SSO is considered a security feature
Technically it's an anti feature...
The "feature" you are talking about is really identity management not sign on (which, btw, users have different identites, outside of the scope of a single company).
At its core it's just a delete function for a username. Putting that in a script with http access should be enough (and not put behind a ridiculous price tag).
Separate services otherwise are enough, no need for SSO.
> At its core it's just a delete function for a username. Putting that in a script with http access should be enough (and not put behind a ridiculous price tag).
Can you explain more about how this works for SSO?
Let's say I'm trying to launch a product (which I am), and want to have SSO as part of the package (which I do), how do I implement what you just said?
I looked into SSO services and they're bloody expensive, so if I can cheaply do it myself, I will.
The comment about being a 'toy service' is disingenuous...
The comment about customers is possibly valid, the difference entirely your use case. If you consume services as a corp, and your goal is to be able to decouple any employee quickly, then you do not need SSO, assuming each service you use allows you the option to delete by username (with proper auth, ofc).
SSO is only needed when you want to give a customer federated access (ability to assign roles without activation on their part). For an internal corp it is largely unnecessary and a convenience thing not a security one (it is much more secure to require different passwords for every service versus a global SSO credential that gets you everywhere).
If your "customers" are your own employees, then this is your decision not a use case or a business requirement.
You're barking up the wrong tree: I communicated how SSO's value prop is defined by essentially the entire SaaS industry... if you have a problem with that value prop, Okta alone is 13B worth of short potential for you once everyone realizes they could just use a script with http access.
SSO Tax is a fun meme, but it misses the point: Whether it's 5 people or even 3, you've scaled your business enough to hire people who aren't in the inner circle.
That's a fair place to consider you an enterprise.