
Vendors who charge extra for single sign-on - Taurenking
https://sso.tax/
======
Spivak
> In short: SSO is a core security requirement for any company with more than
> five employees.

Which kinda gives the game away, right? It’s not that SSO is a luxury feature
but that it’s an IMMEDIATE signal that you’re dealing with an org that can
afford to pay.

It’s absolutely a security feature but that doesn’t mean it should be free for
any reason other than I don’t want to pay for it. So I wish them the best in
bullying the companies into giving me free things. We just dropped $100k on a
security product last week so I’m in the market for freeing up room in the
budget.

~~~
tptacek
That's self-reinforcing. SSO is an immediate signal that your org can afford
to pay because SSO is so expensive, and SSO is expensive in part because the
entire ecosystem is expensive enough to make IDP per-seat licenses a smaller
fraction of the overall bite.

SSO isn't optional; startups of basically all sizes should be using it, almost
from the jump. It's not a thing you're supposed to invest in when you finally
hit, like, 100 employees or something; it's as important for a 5-person team
as a 20-person team.

I get the concept of price discrimination and have no on-spec moral qualm with
it. But charging extra for SSO is no different than charging extra for MFA; in
fact, MFA as a feature is _harder_ to deliver than SAML.

~~~
statictype
>startups of basically all sizes should be using it

We've routinely deployed our softare to customers who pay us 7 figures. We
have literally had to enable SSO only twice in the last 5 years.

There's a difference between _should_ and _actually does_.

~~~
tptacek
I agree. But part of that is because the whole ecosystem of SAAS services
charges 2-3x just to enable it.

~~~
statictype
Perhaps. From our experience SSO is synonymous with “ADFS”.

So maybe we’re biased there. It never occurred to me that SSO would be used by
smaller orgs so we never bothered putting that into our base pricing.

------
sokoloff
I think SSO is a pretty effective feature upon which to do feature and price
discrimination. It’s a value-based pricing choice, not a cost-plus pricing
choice. Engineers are frequently uncomfortable with such pricing decisions.

~~~
closeparen
Yeah an organization with SSO almost certainly has deeper pockets than one
without. Maybe not if it’s just _slapd_ , but SAML = money feels fair.

~~~
eropple
From a difficulty/cost perspective, implementing OIDC as a service provider
literally takes half an hour. (I did it this week.) It's neither complicated
nor complex and it doesn't rate the eye-popping premiums that are being
charged for it.

From a value perspective? If you want the current woeful state of security to
continue, sure, maybe you can argue that it's a good idea to charge more for
tools to better secure a business's operations. But that sucks. We should be
encouraging small businesses to properly secure their ops, because it very
well may be _our_ data that they're dealing with. And we shouldn't be
encouraging service providers to make that harder.

~~~
mattrp
You just made the case for higher pricing. If it’s that valuable then it’s
worth the price to secure it. It’s not that sso costs money to implement it’s
that the price is tied to value of the data and the organization security
needs.

Edit: I do agree with you that a lot of enterprise pricing can feel like the
vendor simply figured out a % of your ebitda and decided it sounded good to
them. But in the examples in the article, most enterprise pricing was fairly
well documented / published. If you want to really get into some of the bad
actors don’t look at the list from the article, look at the enterprise
platforms that are easily into the hundreds of thousands per month... I won’t
name names but if your an enterprise IT manager you know who they are.

~~~
eropple
No, I made the case that it's a public good to hold that the trivial effort
necessary to provide better security can't in good conscience be an upsell.
Making it harder to assume a good security posture is bad citizenship and
should--frankly, must--be opposed. People are harmed when companies think
"security" is an optional feature, and that's not acceptable from either a
vendor or an end implementor.

~~~
mattrp
To be honest, I find it very difficult to argue against the point you're
making. I think it is somewhat logical to have SSO be the demarcation between
individuals and enterprise, but if I rewind a decade or so, I imagine the line
then was HTTPS (which today is totally ridiculous -- everything is/should be
HTTPS). If I could go one step further, I think it's completely wrong for SaaS
to blunt force security policies on user's accounts (i.e. ACME would like the
ability to read/write to your Google profile). I think enterprises should be
able to enforce their policies on the SaaS provider rather than the other way
around. And to build for that...I think is going to be a little more complex
than a typical user/pass. Maybe everything should be a little more expensive?

~~~
eropple
There's a whole tier between "individual" and "enterprise", though, and it's
called "small business" and they probably have a lot more of your (and my)
stuff than we'd be comfortable having YOLOed around. ;)

Enterprises forcing their policies is pretty easy if they're an SP to your
directory, FWIW. I've had great success with Okta for this, but I've written
SPs that talk to arbitrary OIDC providers and it works pretty well too.

------
crazygringo
No, it's just simple and good price discrimination.

Don't think of SSO as a "tax" you have to pay on top of what is otherwise a
cheap and fair base price.

Rather, think of the enterprise price (which includes SSO) as the fair base
price that allows the vendor to stay in business and pay their costs.

While everything else (non-enterprise) is severely discounted, in the hopes
that if you do become enterprise you'll pay full price then.

And you need _something_ to prevent enterprises who can obviously afford to
pay, from buying 1000's of seats at discounted rates. So you discriminate
based on something they absolutely need: SSO.

It works really well.

~~~
w-j-w
But this just means that small companies are more permanently priced out of
SSO. Small companies should be using it to be more secure, but that list gives
you a pretty good idea why they can't.

~~~
georgebarnett
I'm interested by why you think this. In the scheme of costs of having
employees, the software costs are very low.

------
wldlyinaccurate
I just finished adding SSO to the (very small) SaaS company that I work for,
and this page gives me mixed feelings.

Yeah, SSO is a security feature and you expect to get security for free. But
SSO is not free for us as the service provider. We pay a vendor (Auth0) a
decent amount of money to handle all the hard stuff. We also have to manually
set up SSO for each of our customers who want it, which can take anywhere
between 10 minutes to several hours depending on whether the customer has set
up SSO before. For these reasons, we charge an annual fee for SSO on top of
the regular subscription fee. We're just not big enough to absorb the cost.

~~~
scarface74
I agree. We are B2B company and while we include the price of SSO with the
contract, we also only work with “whales”.

It takes us about two or three hours of coordinating with our client to
configure SSO and that’s if they only use it for authentication. If they use
it for authorization also where we base their permissions on claims they send
us - as oppose to an admin in their side configuring their users - it’s a lot
more coordination.

We host our own Ping Federate instances.

------
vageli
How many times do we hear complaints from the community about open source
shipping with insecure defaults, yet we expect security to be a premium
feature we must pay for from SaaS?

------
ru552
I work at a place that has banned the use of SSO because it allows an attacker
to compromise one set of credentials and have access to everything. Good times

~~~
oxguy3
That's what 2FA is for!

And even with SSO, your credentials don't have access to everything, because
no one employee should have access to everything. People should only have
access to the IM channels, git repos, etc that they are actually involved
with. Admin accounts and especially critical systems should be set up to
require separate/additional authentication.

------
Azeralthefallen
Why isn't Auth0 on that list? For most enterprise customers SAML is required
for SSO. However SAML is locked behind their enterprise plan (and enterprise
is stupidly expensive).

On top of that now enterprise plans now require you to pay by connection as
well. So if you want to allow multiple customers SSO connections the cost
starts increasing drastically.

~~~
wldlyinaccurate
Auth0's pricing really disappointed us, but we don't have the resource to
switch to another vendor at the moment. We're a SaaS who need a few dozen
enterprise SAML connections, but each connection only has 5-10 logins per
month. Their sales team flat-out told us that our only option is the $25k/year
enterprise plan plus more for each connection. It's totally bonkers.

~~~
barrkel
SAML is not that difficult to support in Rails with few Ruby gems; took us a
couple of weeks to implement, most of that sorting out various integration
snags with customers.

(SaaS with 5 to 500 logins per customer)

------
sergiotapia
Please add Clubhouse and Notion to that list.

[https://clubhouse.io](https://clubhouse.io)

[https://notion.so](https://notion.so)

~~~
robjan
They accept pull requests: [https://github.com/robchahin/sso-wall-of-
shame](https://github.com/robchahin/sso-wall-of-shame)

------
derekperkins
The list is innately disingenuous. For most of these products, SSO isn't the
sole differentiator between pricing tiers, there are also significant
functionality differences.

~~~
tptacek
Who cares what the other differentiators are? If you have to pay for all of
them to get SAML, then that difference is what SAML costs.

------
Bhilai
So companies should have a moral responsibility to give away security features
for free ? There is certainly a cost incurred while implementing such
fesutres.

------
underyx
Heh, the GitLab on-prem pricing note of "$4 per u/m²" looks like "4 dollars
per user per square meter".

------
yellow_lead
So security should be free? That kind of implies something about its worth
that I might not think is the author's intention.

~~~
vageli
> So security should be free? That kind of implies something about its worth
> that I might not think is the author's intention.

By this sentiment, does Let's Encrypt debase the value of security as well?

~~~
yellow_lead
Good point.

------
cs101
What does the unit "u/m" mean?

~~~
bbx
Per user per month.

So Slack's "$6.67 per u/m" means each month you pay $6.67 for each user who
has signed up. Your company has 20 users? You pay $133.40 each month.

------
gavinray
I understand the list of companies provided here are fairly large businesses,
but the text in the post seems to send a different message.

Maybe I am misinterpreting this, but I have had this conversation quite a few
times in the past month alone with other engineers and execs, and I have to
take an entirely different stance.

If you are trying to bootstrap a SaaS start-up (or even if you arent and just
want to be frugal and/or keep technical complexity low) I do not think that
outsourcing your authentication to a third-party provider, especially at cost,
is necessarily the best choice.

A) In the developer community chats I am in, the auth provider that pops up
the most in conversation is Auth0. Personally, I do not see how they stay in
business because their pricing is (in my opinion) egregious. $228/mo for
10,000 monthly active users. However, they do have a free plan up to 7,000
monthly active users. The sheer volume of people who continually bring Auth0
up means that they either build products which never gain significant traction
& have never had to scale, or have money to blow. So there is the cost-factor
argument.

B) While you can make the argument that the vast majority of people have
accounts with SSO providers, I would play Devils Advocate and say that there
also exist people who are uncomfortable either providing that identity
regardless of the anonymity/security meaures in place, or because they do not
want to associate an identity from a primary authentication provider with your
site/service. So there is your please-the-people argument.

C) From a technical perspective it CAN be easier not to opt for SSO
integration. What I mean by this is, for the past half-decade, the majority of
the products I have built have used bcrypt-ed passwords. And that works just
fine. For getting things off the ground you can go far with a solid password
hash-and-compare implementation.

Something roughly like the following is free, super easy to implement, and
covers a large percentage of usecases:

\- Store password with an algorithm like bcrypt or Argon2 on sign-up, compare
on login

\- Opt-in 2FA by using OTP via SMS or email

\- Issue a SecureRandom session token each time a user logs, and use it as the
identifying mechanism in a JWT or similar

\- Make your auth logic verify the JWT and look the user up by the session
token

\- You can emulate the blacklisting/all-token revoke functionality major auth
providers have by clearing one/all session tokens in the DB

I am sure someone who knows much, much more than me about security show up in
the comments below this and tell me I am idiot, but this is my two-cents at
least ¯\\_(ツ)_/¯

(Side note edit: I think that there is a burgeoning problem in the developer
community where new engineers reach for the easiest thing and wind up with a
stack full of nothing but X-as-a-service, which in this case includes
authentication. I am not sure how many junior devs could implement basic
password-hash JWT authentication from scratch. The fact so many of them are
readily paying $2,500/yr per 10,000 users for JUST authentication is mildly
terrifying)

~~~
windowsworkstoo
The other side of this is as an org, with say 5 - 100 employees, who are all
on Okta for example - and want to be able to login to those systems listed
using their single Okta creds - this isn't being an about implementing an auth
system to authenticate a bunch of users, but being able to give your employees
easy, auditable access to the 10 - 30 SaaS product they use daily, via SAML or
OIDC

~~~
gavinray
Ohhh. I'm a bit slow; yeah for sure that makes a ton of sense then.

------
omarish
"A website written by someone who doesn't understand enterprise pricing"

