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.
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.
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.
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.
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 :(
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.
scott_w|1 year ago
- 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.
ArchOversight|1 year ago
bkuehl|1 year ago
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.
justin_oaks|1 year ago
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?
eastbound|1 year ago
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.
Roguelazer|1 year ago
revicon|1 year ago
hluska|1 year ago
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.
tqwhite|1 year ago
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.
sloankev|1 year ago
smitty1e|1 year ago
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.
jeffdubin|1 year ago
fmajid|1 year ago
https://arstechnica.com/information-technology/2023/11/no-ok...
ndriscoll|1 year ago
jauntywundrkind|1 year ago
daft_pink|1 year ago
dijit|1 year ago
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.
jameskilton|1 year ago
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).
ArchOversight|1 year ago
The SMB's already have SSO, they just don't enable it for the SaaS products they buy because of the price.
Dachande663|1 year ago
dswalter|1 year ago
dijit|1 year ago
justin_oaks|1 year ago
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.
scott_w|1 year ago
delfinom|1 year ago
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.