[flessner]

As a customer that process makes sense if I had those extra requirements, but why do so many SaaS lock SSO (Google/Microsoft) behind their Enterprise offerings?

I get that it's for differentiation between plans, but as a customer it feels weird to walk into this pricing black hole just for SSO. Maybe you have some experience with that?

[SOLAR_FIELDS]

Most SaaS companies will tell you that they would rather not lock this important security feature behind enterprise. But the reality is that it is one of the few things enterprise will pay for and gate on and as such it’s become very effective as a differentiator. The edict to gate everything behind SSO is powerful in large enterprises and as such they will absolutely pay to be able to do that, making it a very easy internal sales tactic. The market has spoken, for better or worse.

[mlhpdx]

I read your comment as saying that SSO is denied to “regular” (non-enterprise) customers because enterprise customers would buy the regular product if it was included there, thus pointing out that all the other “enterprise” needs (terms, etc) aren’t real?

[wongarsu]

Most enterprise features are nice-to-haves. SSO is a must-have for companies with enough security or compliance ceremony, which includes most enterprises.

[coding123]

Small companies don't need sso because when an employee leaves, they just go into all their sass and remove the user or change the password. A large company can't work without SSO because in an org with hundreds of users they can't login to each SASS and disable and enable everyone coming and going at the company, which is many per month in some cases.

[fullspectrumdev]

If smaller/early stage shops adopt SSO and other sensible practices early on, it makes scaling easier and cheaper in the long run.

I’ve gone through a few “migrations to SSO” after years of non-SSO with customers in the past and it’s a fucking expensive nightmare.

[nlitened]

> I’ve gone through a few “migrations to SSO” after years of non-SSO with customers in the past and it’s a fucking expensive nightmare.

Yet the customers still paid, so it was worth for them.

[Terretta]

> Small companies don't need SSO

This is incorrect.

[TeMPOraL]

This is very much correct, and quite self-evident: they live without, therefore they don't need it. Wanting something != needing it. Companies that actually need SSO are the ones that have internal or external compliance requirements, and/or for which managing users without SSO becomes prohibitively expensive. Turns out, at that point, they're willing to pay through the roof for it.

[Terretta]

> quite self-evident: they live without, therefore they don't need it

Lots of people live without things others observe they need. Doesn't make going without a good idea.

> Companies that actually need SSO are the ones that have internal or external compliance requirements...

This logic is backwards.

Why do you think SSO is a "requirement" that security certifications or compliance policies look for? Why did that come to be? Who does SSO benefit? Are those personas relevant for only large companies or small ones too?

Do beginning drivers not “need” seatbelts or brakes? Or are these devices only needed to avoid tickets and pass inspection?

[SOLAR_FIELDS]

One thing worth pointing out. If you don’t mind using GitHub or Google you can get “SSO at home” for a lot of things, since most SaaS provide Google/Github login in their lower priced tiers. It will usually be OIDC based and not SAML, but it’s definitely possible to use these providers up to a quite significant scale.

[0x457]

Why? You use SSO in your personal life all the time. Why would you not want to continue doing so in your business?

If anything, small companies need SSO more than any others - those companies usually outsource a lot (SaaS vs a dedicated hire), managing credentials is annoying.

[Terretta]

So we agree that small companies do need it.

[kccqzy]

Depends on the definition of "small" which I take to mean early stage startups.

[Too]

SSO has lots of other benefits. MFA primarily. This is non negotiable these days, even for the smallest company. I’ve not seen many services supporting this without SSO.

Don’t get me started on the services that have their own smart ideas on what constitutes a safe password. Max 8 characters with no repeated letters and of which 4 must be an emoji, with automatic logout every 12 minutes. Yes those still exist.

Password policies are things you want control over in your IdP to avoid all this BS. SSO really should be standard.

[TeMPOraL]

> This is non negotiable these days, even for the smallest company.

Says who?

In reality, users don't care. Regulators, however, sometimes do, which leads to certifications and compliance requirements - and only then SSO and MFA become non-negotiable.

[cjcampbell]

I work with a variety of small companies (5-25 FTEs) that are increasingly facing strict MFA requirements in order to maintain insurance. SSO isn’t an explicit requirement, but there are a myriad of general access requirements that they struggle to follow without some level of centralization via federated identity/SSO.

[Terretta]

So add a cost to regular pricing as a checkbox, and let people not talk to you.

[OptionOfT]

As a company, I much rather not deal with passwords, MFA, and password/MFA-reset procedures. That costs money to develop and maintain.

Storing ClientID and ClientSecret for OpenID, or some keys for SAML per customer is much easier, and a lot less risky.

After all, I'm in the business of solving (insert SaaS problem), not in the business of solving authentication.

[nunez]

Because SSO outside of the OAuth2 happy flow [0] can be a pain in the ass to develop for and support.

Some customers use Okta; great! But some of those customers have Okta configured in ways that don't work with your auth service. Some customers use Okta as a downstream to their _actual_ IdP, which could be Keycloak (a million different ways to configure that) or, god forbid, some custom thing they wrote. You've gotta support that.

Some customers (the ones that will pay the REALLY big bucks) use Active Directory Federated Services and SAML-based auth. SAML is XML/SOAP. Gigantic pain. Gotta support it.

Some customers want LDAP/LDAP-S based auth. Gotta support that.

Given all this, it makes much more financial sense to lock that behind customers who are willing to pay the big dollars for enterprise-y features AND support instead of dealing with infinitely long support tickets.

[0] There is no such thing as a happy OAuth2 flow.

[vinckr]

Its pretty trivial to support the use cases you mentioned with Ory OAuth2/Hydra and Ory Kratos.

LDAP is harder, but IMO you dont need it unless you operate in a very specific industry.

[xyzzy_plugh]

In my experience SSO is high-touch. Sure there are self-service portals and control panes but big company IT departments are ticket processing machines, and it becomes a game of broken telephone to make changes. When something doesn't work, what do you do?

Offering SSO as part of an enterprise SKU offering implies there is a high-touch relationship out of the gate, and that there is a higher chance of success and adoption, including getting SSO set up right.

Furthermore many large behemoth corporations have strange SSO configurations and it's not unusual to require bespoke configuration let alone debugging time.

[Terretta]

Custom SSO, fine.

But "Sign in with..." or "Continue with..." M365 and Google gets you almost all SMB, and with Apple gets you individuals who spend money.

Add a domain check and you have the quick and dirty equivalent of SAML SSO without any touch at all.

https://id.atlassian.com/login

https://www.xsplit.com/user/auth

[tetha]

This is the strategy we're adopting at work.

People are currently implementing a simple self-service for common SAML and OIDC providers, like O365 and such. This will be free and recommended for all customers to use, because I believe in providing actual security for our customers.

And then you can order a consulting project on top to figure out a good way to import user groups, user identities and such into the platform, and ideally to integrate our preferred group structures with a customers existing approval and group structures. This also includes help to initially connect us to the IDP. This is priced at a relatively cheap consultant level.

And then there is a second tier of consulting projects if the customer is using a non-standard IDP and can't do it on their own. Like, we have one customer that has an in-house developed SAML provider, but the original people who worked on it aren't there anymore. That was an interesting project and I learned way more stuff about SAML than I ever wanted, and also fixed a bug in their SAML provider code. This is priced right between "subject matter experts" and "no".

That's what I consider a very fair split. Simple SSO for everyone, especially on standard providers. And if you want to save a day or two of your identity and authentication teams, you can hand us some cash to do so. Smaller customers generally won't need this, they usually just have 1-2 groups they want to push and that's easy to do, but large customers with complex directories and many users in different departments like these projects a lot.

[walterbell]

See the "Free SSO providers" column at https://ssotax.org.

[kuschku]

Go ahead, make SAML, Kerberos, LDAP, whatever custom solution paid. But OIDC should be free, ideally even with my own Keycloak. Go ahead and put all the customizations in the paid tier, again, fine. If I want user/role mapping, I can set it up in keycloak.

But it's silly paying more than a FTE's salary just for the SSO tax when you've got 5 people.

[michaelt]

> why do so many SaaS lock SSO (Google/Microsoft) behind their Enterprise offerings?

"Price discrimination" is a pricing strategy where very similar products are sold at different prices in different market segments.

Imagine you've invented an amazing silver bullet that makes software developers 30% more productive.

For the likes of Google who pay developers $200k/year, getting 30% more productivity would be a great deal even if you were charging them $10k per user per year, because that productivity boost is worth $60k.

For unpaid students, casual users, open source projects and cash-strapped micro-businesses - a 30% improvement in $0 is still $0 so they can't afford much. Maybe $50/user/year, and they'll still complain like hell about it. But it'll help your tool spread and build word-of-mouth.

So how do you price your product - $50 or $10,000?

With "price discrimination" you can do both. Offer a cheap tier for home users and micro-businesses, and an enterprise tier with features Google desperately wants, at a much higher price.

By having prospective customers call for pricing, your sales folk can research each customer and figures out whether they're the kind of place that pays their developers $200k/year or more like $30k/year - allowing them to figure out how much the product is worth to that particular customer.

[codegeek]

also known as https://sso.tax

[mathiasn]

or even better https://ssotax.org

[mtmail]

I don't have experience with SSO. It's a typical feature SaaS tries to charge extra for (https://www.enterpriseready.io/#features). Maybe they don't have an add-on feature in their billing app.

[mbesto]

I tell you why: SSO means I'm going through a qualified purchasing route, which means getting finance/procurement and then subsequently IT involvement. SSO implies I'm using the product company wide, versus a group of 2~10 people in the marketing group. As others have mentioned, there is a very justifiable reason to have a relationship between sales and procurement/IT.

Unpopular opinion - you may like to call it an SSO tax, but I think it's perfectly reasonable from both sides. The reality is - if you're a 10 person startup and the "SSO tax" is annoying, then simply don't do the SSO version...you have 10 people in your company, you can get them all to use a password manager with MFA. If you're worried about security then fine, don't you think it's worth paying a little more?

If people's issue with the "SSO tax" is that the SaaS software provider is making incremental money for very little effort/investment, then I would love to explain how the economics of most SaaS tenancy models work with regards to infrastructure spend...

[Terretta]

Having been an infrastructure provider for 30 years, this answer is largely unjustifiable.

It's a bunch of handwaving to try to get price discrimination for a "how the Internet is supposed to work" standard everyone, even a single dev client of the SaaS, should be using.

And that the SaaS provider should be pushing so they don't have the liability of subscriber credential database protection ...

[mbesto]

> even a single dev client of the SaaS, should be using.

Having assessed 600+ software companies (many of which are 5-50 employees), I'd say about half of them use MFA consistently across their business. And it's not a budgetary issue, but more of a logistic/IT/prioritization one.

[kuschku]

It'd be 100% if SSO was commonly included.

[DandyDev]

10 person startup -> that is a strawman if I ever saw one. There are many 100 person scale ups that are pre-profit for who the hassle of managing separate accounts for X SaaS tools for 100+ people is justifiably too much to ask but who can also not justify paying literally 50x as much as the highest non Enterprise tier

[mbesto]

> literally 50x

This is literally not the case. The pricing is nowhere near 50x - in fact if you negotiate the rates are only marginally higher than the tier below it.

FWIW - the sentiment I get here is that the gripe isn't necessarily the pricing (you notice how no one has quoted specific increases?) but that they have to pick up the phone to talk to someone for what they believe to be such a small feature.

> There are many 100 person scale ups that are pre-profit for who the hassle of managing separate accounts for X SaaS tools for 100+ people

So you're telling me that a company is complaining that they have to pay extra money for features that reduce their administrative burden and limit their risk, thereby costing them less money? Explain that one to me...

> There are many 100 person scale ups that are pre-profit

Also, put yourself in the seat of the owner of a software provider, would you rather win the sales opportunities of 10,000s of businesses that aren't pre-profit or the hundreds of businesses that match your criteria? I know who I'd be marketing to...

[TeMPOraL]

Startups/scaleups can grow arbitrarily large pre-profit; that's not a feature, that's a bug.