- Positioning: it’s seen as an enterprise product so attracts enterprise pricing
- Support: it’s genuinely a high touch feature which lots of customers fuck up all the time in the same way and always needs support and engineering help.
Documentation for those issues? We have it, it doesn’t stop the support requests coming in. I was looking at a request this morning where the error message is coming from Azure itself and clearly says “this is not configured correctly.” The request hasn’t even reached our systems yet!
Until SSO is as plug n play for users as Google Sign-in, SSO will continue to attract a high price point. And I’ll continue to push back on attempts internally to democratise it.
Sound familiar?
People just don't seem to understand that to do SSO properly and securely for your app it costs decent money and support time. Regardless of if you roll your own or buy 3rd party (recommended). We do include SSO by default but we really only sell to enterprises and the price is baked in. A lot startups won't have that luxury.
I noticed that Slack offers "OAuth with Google" for their Pro plan (lowest paid tier) but SAML SSO requires the more expensive Business+ plan.
Would it make sense to allow everyone to use the "easy" SSO and require higher payment for stuff that's complicated and easy to screw up?
The main benefit of SAML comes from the permission management and standardisation across systems. Its also what starts to make it complex beyond just writing the code.
Seen? SMBs need to be SOC2 (et al., such as PCI-DSS or HIPAA), and the requirement of controlling all accounts’ permissions at all times is often fulfilled with SSO. How else would you “reset the user’s password after 3 attempts” if the attacker can try the password 3 times on… all of your intranet websites? let alone on Cloud products.
SOC2 is indeed seen as an enterprise feature, but giving access to SMBs strengthens the global security landscape.
Then charge your customer for it.
> but giving access to SMBs strengthens the global security landscape.
How does giving away an expensive-to-support feature “strengthen the landscape?”
He’s an excellent guy with a great attitude and a genuine love for what he does. He’s infectious and when I get to see him, I usually laugh so hard I damned near hyperventilate.
His SSO issue was so severe that all that good humour and attitude was totally absent. It took a couple of days, but we got him going.
I’m a big fan of democratizing tech, especially security tech. But SSO is quite complicated at the best of times. When it goes wrong, it’s like troubleshooting a plate of spaghetti where half the noodles try to bite you.
In the case of SMB, when it goes wrong their businesses mostly grind to a halt. They often don’t have dedicated IT staff - the model of a son’s friend who comes in to help because he didn’t move away is quite common in SMB.
It’s a good idea, but in practice until we can get it to be completely turnkey, I don’t believe that many SSO providers could even afford to provide support for SMBs.
Until Apple and Microsoft find a way to a LetsEncrypt-type comprehensive mission, it's out of the question.
And, since Azure 'Entra' is a Microsoft profit center, no easy to use tool will be in their interest.
OK, so SSO==OAuth.
What TFA doesn't mention is that we're enabling surveillance capitalism by SSO.
"Who owns the customers" might well be an SMB consideration.
Granted, it lacks some of the benefits of SAML, such as permissions assignment from a central source. But this is also why those features are so pricey: enterprise organisations derive the most benefit from it, and have a team dedicated to its maintenance.
SSO doesn't have to be Google, Azure, Okta, PingFederate, you can run a stand-alone instance of Keycloak for instance and have OIDC and SAML available to provide SSO functionality.
https://arstechnica.com/information-technology/2023/11/no-ok...
However, you're rather naive if you think this is what would keep you locked in, changing authentication host (usually tied to mail, calendars, chat) is... difficult, and changing the SSO stuff is one of the easiest parts of the migration speaking from experience.
SSO is quite useful when you have onboarding and offboarding, remembering every place a person had an account with access to critical company data is horrible and trying to convince people to not share passwords between them is horrible too- a breach in one, in those cases, is a breach in all.
I glanced through the report and it comes to the normal conclusion that SSO is hard and expensive to get right. Do SMBs focus on providing value to their customers in the problem space that they are experts at or do they spend months just getting sign-in working?
Yeah I get the concern about the "SSO tax" but unfortunately SSO isn't free. Someone is paying for it somewhere, be that implementation, outsourcing to a service, and/or maintenance and customer support for the live of the product.
That said there are a lot more services and libraries out today that try to make this easier such as https://www.passportjs.org/ (which WorkOS sponsors).
The SMB's already have SSO, they just don't enable it for the SaaS products they buy because of the price.
Except Entra ID for customers, which is fairly priced and has a magic “just works automatically for any M365 customer” feature. It is quite stupid and confusing in many other ways but at least it makes fiscal sense.
Unless you're more specific, I'm going to assume that that "way" is the wrong way.
Initial login shouldn't add more latency than a couple web redirects. The authentication token/assertion should be validated only once and not be needed until it expires or the user logs out.
Bullshit article. The reason SMBs don't deploy SSO is because SaaS and other tooling puts SSO integration behind very high tier paywalls.
I'm talking pricing schemes where sure, you can sign up for a 20 person team on a service because that's the only expected user base in house, but the moment you ask for SSO they demand you license your entire employee headcount.
Among many ridiculous schemes I've dealt with.