Why SMBs Don't Deploy SSO
cisa.gov
Why SMBs Don't Deploy SSO
1–10 of 59 posts
Re: Why SMBs Don't Deploy SSO
#2Missing 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.
Re: Why SMBs Don't Deploy SSO
#3Missing 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.
Forced two factor auth can often solve this kind of thing though.
Re: Why SMBs Don't Deploy SSO
#4I'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.
Re: Why SMBs Don't Deploy SSO
#5Re: Why SMBs Don't Deploy SSO
#6As 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.
Re: Why SMBs Don't Deploy SSO
#7I don’t want to bother with vendor lock in and an additional single point of failure. That’s why I don’t use sso
Re: Why SMBs Don't Deploy SSO
#8I've implemented SSO in a small business context. It's insanely hard. Absolutely not worth it.
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.
Re: Why SMBs Don't Deploy SSO
#9Full 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).
Re: Why SMBs Don't Deploy SSO
#10I don’t want to bother with vendor lock in and an additional single point of failure. That’s why I don’t use sso
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.