What's the difference?
See https://sso.tax/ for details but I'll quote this from it "SSO is a core security requirement for any company with more than five employees"
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.
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?
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.
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.
SSO is hairy enough that you can't write it from scratch in any reasonable amount of time for what a typical SaaS needs.
There's OSS SSO you can host yourself that supports enterprise : https://www.keycloak.org/
If you're B2C Firebase Auth is cheap, and doesn't actually require hosting on Firebase
I expected so, looking at how much it costs to provide just SSO as a service.
Thanks for keycloak, didn't know about that.
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.
If you think you need SSO and but you do not have the budget for upgrading to their enterprise tier, may be you are not the right customer that they are targeting to sell. It is not you, it is them.
I wasn't thinking as the service provider that needs a way to force the folks with the big bucks to pay up.
It sucks for the little companies, but it may be necessary for the service to do so.
SSO is expensive, adding maybe $10/user/month if the team adds in a purchased solution (passing the cost directly onto the client).
If the customer doesn't want to pay for it because they aren't an enterprise, you can't blame the supplier for not supplying it at a lower price than $10/user/month.
BTW, I did just this this morning. The AE came back to offer the enterprise package for the price of the mid-tier package.
While we acknowledge the reasons behind SSO being in the enterprise tier, we're all on a collective journey to enhance our security measures. Open Core models are indeed a good option (my preference), yet the dynamics vary across solutions and industries. It's up to each of us to explore, experiment, and discover what resonates with our market. In doing so, we can foster growth while maintaining our commitment to supporting the community in the long run.