As someone who works on our SSO implementation, the reason for the SSO tax is twofold:
- 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.
I feel like a lot of the issues are also due to Azure making it vastly more difficult than necessary to configure OIDC/SAML and get the right information over to the SP.
I don’t doubt that, however the vendor doesn’t get a choice over the IDP and Azure isn’t even the worst! Last week we had to create a custom Metadata XML file for a customer because their IDP doesn’t accept self-signed certificates. For a certificate we send them. That we can validate on a call with them. And it’s completely undocumented in their IDP’s docs.
"Your issue is coming from a misconfigured SSO. We disabled SSO on your account, you can login with the standard password reset flow. You can reenable SSO once you have fixed the issue."
Azure AD or whatever they are calling is now isn't even fully SAML 2.0 compliant, so of course it generates support calls. Then the answer from MS support is "use this workaround" and now your implementation is locked into Microsoft's implementation.
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.
SAML is way more of a beast to configure and maintain compared to any oauth-based flow.
One reason is just that SAML is more complex, because it does a great many different things for many different use cases.
The other reason is that setting up SAML requires humans to coordinate the trust setup and key exchange between the IDP and Relying Party.
For typical setups, oauth is pretty much self-serve, but where I worked setting up a new SAML customer required a senior engineer to personally handle it every time.
That’s exactly what everyone does. Most even put Google Sign-in into their free plans because it’s a great way to increase sign-ups.
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.
Missing one of the key reasons: most SMBs are sharing seats (usually in violation of the license terms for the products they're using), which is rather harder with good SSO products. Per seat licensing for b2b products is lucrative, but carries the risk that you're just pushing your customers to share passwords, which is usually way worse for security.
Why would that help? Where I work we have a central server with some phones connected that act as the 2FA devices for every service where not all employees have their own account, with an internally developed browser extension that grabs the access code from this server upon login.
Or more primitively than that, I've seen small offices have an old shared phone with a bulging battery that's used for 2fa (or even just having it attached to someone's personal phone and just asking them for the code when you need to log in).
It’s also because there might only be one super admin account allowed, which also needs to be the most secure. But you don’t want the person with the 2FA codes to wander off with them one day!
Only if you require text message based two factor. Password managers like 1Password allow you to store your OTP within them and share that + the password internally within your team
I've set up multiple times a phone-to-Slack proxy for this exact reason. In my case it was a VoIP number, but if that's blocked, Android has many SMS-to-webhook apps and even entry-level industrial LTE routers generally have this feature so you can use a real SIM card.
One of my friends from high school has a dad with a business. I still live in the same city where I went to high school so I occasionally get called to do some tech support for my friend’s dad. Last summer, he ended up in SSO hell and so I got loaded on muscle relaxants and went to help him.
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.
> Single sign-on (SSO) is a mechanism for outsourcing the authentication for your website (or other product) to a third party identity provider, such as Google, Azure AD, Okta, PingFederate, etc.
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.
Agreed, they’re conflating things like Google Sign-in with enterprise offerings like SAML. Companies generally give away Google Sign-in for “free” as it’s a great growth vector and gives SMEs a sort-of SAML setup for low cost. It’s also really easy for the vendor to support: you just click the button and you’re in.
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.
They aren't conflating anything. OIDC or SAML should not be "taxed" extra.
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.
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.
There likely is an off the shelf OIDC SP provider you can use for the actual "hard parts".
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.
My advice would be to wait until a big enough customer is willing to pay through the nose for it. You’re “lucky” in that you charge per user so it’s easy to model into your pricing :)
To be clear, SMBs should be allowed to use Google Sign-in or Azure’s equivalent for the base pricing. I think this is table stakes for features (and security).
SAML? No chance. SMEs don’t need it and my comments above explain why vendors will never offer it.
Google Sign-In is locking people to using Google's infrastructure. If an SMB has already deployed using Azure you don't get access using SSO, instead you have to fall back to username/password?
Adding support for OIDC is not that difficult. I prefer OIDC over SAML anyway, but neither is that difficult.
> 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?
The issue isn’t writing the code. It’s everything that comes after in terms of user support. The systems are relatively easy to integrate with libraries or products like Auth0.
In which case, I’d look at the documentation that companies put out for SSO to get a feel for the types of issues your customers will face. Make sure your system logs everything (or pay Auth0) and provide this as a feature. It’ll cut down a lot of support calls.
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.
If it requires configuration on the user’s end then it’s no better than SAML from the vendor's perspective. We’d much rather choose specific providers to hook into, based on the likelihood of increasing sign-ups.
The SMB is the customer, they should already have a single place for all their users and for authentication.
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.
The org I work for recently signed a small (5-user) enterprise agreement with a popular web-based form solution provider for $5k. When I asked them to enable SSO, they asked for an additional $2.5k, which I felt was ridiculous. This is why we didn't do SSO.
SSO doesn't have to mean you delegate anything. You can run e.g. a saml identity provider on-prem with no public Internet access. The browser--being on the vpn--can reach both the identity provider and the application, and can pass along the necessary assertion even if the application cannot talk to the identity server. The application itself may or may not be on-prem as well. I worked on this exact setup for some SaaS software for banks. Our applications were in AWS and we never had any ability to reach the bank identity servers.
They should use YunoHost! By far one of the most impressive things about YunoHost is that a good number of the services you can run with it have directory service integration! https://yunohost.org/en/users
SAML and OAUTH2 are open standards, and single-point of failure generally means a single server or host- but I take the point that having a centralised service becoming unavailable would affect new logins.
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.
Full disclosure: I work at WorkOS (https://workos.com/), we provide SSO (among other things) as a service.
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).
SMB's are the customers of products that offer SSO but only at the enterprise level. CISA is arguing that the enterprise level of the software SMB's need to operate is too expensive and thus SMB's don't end up buying a license tier that includes the ability to hook into their already existing SSO (likely Azure Entra ID or Google Workspaces, sometimes Okta).
The SMB's already have SSO, they just don't enable it for the SaaS products they buy because of the price.
We’re current users of workos, for both the SSO and directory sync (which I love) features, but unfortunately the pricing means we have to charge our customers more for it. SSO+DS exceeds the cost of our base plan leading us to having to look at other alternatives and move away eventually :(
Same here. As a SaaS provider to SMB, all the major auth vendors (Okta, Ping, WorkOS, etc.) are ludicrously overpriced and would require us to double our own pricing.
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.
I'm largely in favor of SSO, but it's not without its downsides, going beyond capital costs: SSO can also be implemented in a way that introduces an onerous latency tax when using services.
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.
- 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.