Why SMBs Don't Deploy SSO
cisa.gov
cisa.gov
- 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.
Lock support for SSO up behind a paywall, not the actual feature.
This still doesn’t override positioning. Companies can make more money by charging more money for it, so they do.
Sound familiar?
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?”
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.
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.
Don’t use LastPass though.
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.
I do work for a number of small businesses and they can't afford the "enterprise cost" for things, so there is a shared password vault instead because there is no centralized management of users.
The small businesses all have some form of SSO available, whether they are using Azure Entra ID or Google Workspaces, they have a central location for users, but the cost is prohibitive for most products to get the upgrade to get access to SAML or OIDC for SSO.
SAML? No chance. SMEs don’t need it and my comments above explain why vendors will never offer it.
Adding support for OIDC is not that difficult. I prefer OIDC over SAML anyway, but neither is that difficult.
Since it seems that you know what you are doing (and you've done it before), how about a blog post detailing the steps one would go through when writing some SaaS app for a client who wants SSO?
That's the detail that I need, actually
Budget in time for your engineers to sit on support calls and directly work through them with customers. Document every issue you see for your support team. If you can, hire a semi technical person to do this support (especially if you want to scale up). It’ll take a load off your engineers.
If your permission system allows it, enable IDP-initiated login as a must have.
Have a strategy for if a customer locks themselves out with a bad configuration. You’ll need either to force they have a password account or a way to reach out to Support to turn it off for them to try again.
After that, honestly, the issues will be a grab bag of things. They’re generally one-off issues per customer but they can take time while you resolve them.
Finally, most customers are great and get it. Some are great and don’t get it. The last group think they know more than you and clearly don’t. They’ll eat up most of your time.
But it costs extra. That cost is passed on to the consumer.
The major hurdle is that it's expensive!
Take a typical small business SaaS - providing SSO instead of standard passwords can take more time and effort to purchase or develop and to roll out than the actual SaaS software.
Okay, lets say you buy SSO: offloading to a service is going to cost a minimum of an extra $20/month/user.
Building it? That's going to take months of developer time, not to mention that this is a high-touch/high-feedback feature, which is going to eat up the service employees time.
And then the rollout, which almost always needs a month of external consultants getting everything working correctly.
I'm doing a small SaaS, $15/user/month; if anyone has any good recommendations that aren't going to to cost me a quarter of my current sale price, I'm all ears.
Even if it's DIY, as long as I don't burn a month of dev-time just for integration/deployment.
If you already use something like "Sign in with {Google,Facebook,Twitter,Apple}" you are already doing part of it.
I have built several products now with OIDC support for authentication (not authorization) and it has never taken more than a day or two to wire it up.
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.
I'm fond of saying "Everything is easy, when you know how to do it", but getting these security details absolutely right isn't entry-level.
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.