66 comments

[ 2.6 ms ] story [ 123 ms ] thread
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.
(comment deleted)
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.
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.

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.

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.
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?
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.

Pretend that the lower featured, discounted tier doesn’t exist and that “enterprise” is the lowest tier.

Does that make anything any better for the world?

Yeah I'm not answering that because nobody is actually "discounting" that lower-featured tier, that's a dodge. The base tiers are not discounted. They're the actual price for those features.

And that's completely fine. You can have an enterprise tier with more features! What I am saying--and I understand that you understand this but for your question to have any rhetorical impact must misapprehend it--is that they must not be security-based features as it is full-stop unethical to charge a toll for basic security.

They’re the actual price for those features only because of the subsidy provided by selling SSO to enterprise customers, IMO.

It’s like arguing that economy airline seating sucks and shouldn’t be allowed to be different than business class. Economy is subsidized by first and business. If you legislate away the difference, it’s not the case that everyone now gets a business class seat at the economy ticket price but much more likely that the other equilibrium emerges where only business class service and pricing is offered.

Ooh, analogies. Try this one on for size: "no, you're not allowed to take seat belts away from economy passengers."

This shit is baseline. And if it continues to not be, it's time to get legislators involved. Because that's what we all want, I'm sure.

Setting up hosted Active Directory with AWS is $1000 a year (charged by the hour) and for $reasons you have to use a Windows VM to use it as an IDP for SSO. All in it’s probably around $1500 a year.

I’m sure there are cheaper solutions and we only use our setup for validation testing for our own SSO implementation where we are the SP.

Would Azure AD work?
We are already all in on AWS. $1200 a year is a pittance in the grand scheme of things for a company.
Any company using G Suite has SAML support included, so I don't think any organisation wanting SSO does have deep pockets.
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.

I'm pretty sure Rob (the proprietor) takes suggestions.
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.
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)

What exactly is Auth0 used for besides SSO?
(comment deleted)
> 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.

The complaint isn't that companies are charging money, it's that companies don't include SSO in their base paid tier. We're talking about customers who are already paying money for a service but they're still not getting SSO.
I mean, I was going to point out that that sentence massively compromises the validity of the author's argument, because I've been in companies with more than five employees for which this was definitely not a core security requirement.

It's one thing to say that some feature is actually adopted as a security requirement at many companies and that SaaS vendors who don't offer that feature will lose out on those companies as customers.

It's another thing to say that SaaS vendors are failing to meet a massive market requirement, and that companies on the other side of that market are also failing to "realize" and adopt that requirement. In other words, unless I saw evidence that a larger portion of 6-person companies demanded this feature, it seems reasonable to assume that the market simply doesn't want this feature, and SaaS vendors aren't doing anything particularly stupid by not offering the feature.

> I mean, I was going to point out that that sentence massively compromises the validity of the author's argument, because I've been in companies with more than five employees for which this was definitely not a core security requirement.

no, it was a core security requirement whether or not it was accepted as such. but it turns out that saving money wins out over security until you get owned OR you're making enough money to not care.

I think that's a dangerous game with words. The argument boils down to claiming that customers absolutely need a feature but aren't aware of it, and SaaS vendors absolutely need to offer that feature but aren't aware of it.
this is the state of corporate security! remember, until about 5-6 years ago 2fa and HTTPS were another couple of examples of things people thought were unnecessary.
I think the strongest evidence that SSO isn’t a core security requirement is the fact that people aren’t demanding that every site support “login with $social.”

SSO is net good for security and is a quick way around a lot of red tape in certain regulatory domains but the value prop has always been, and still is, largely administrative.

Having a human manage the accounts of hundreds of people with 10+ logins each services each costs real money compared to adding an account once to AD and dropping them in the group with the rest of their team which is why companies, rightly, feel they can charge a pretty penny for the privilege. Small companies can afford rolling accounts by hand but then you grow and then you have to decide if it’s worth spending the employee hours or the cash.

> I think the strongest evidence that SSO isn’t a core security requirement is the fact that people aren’t demanding that every site support “login with $social.”

The very last thing I want from my bank, insurance company, or what have you is for them to be handing over information about every login I make to Google or Facebook.

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.

So much this - I'm so glad to see this site as it mirrors an exact complaint I have - with hosted directories becoming so popular, wanting SSO should hopefully slowly stop becoming a signal that you are a big org with lots of money to spend.

When my org tries to buy a new SaaS I try to get them to only budget/consider it at the lowest level that gives them SSO - if they can't afford that, then they can't want it enough...it works sometimes...

>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_.

I agree. But part of that is because the whole ecosystem of SAAS services charges 2-3x just to enable it.
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.

Having set up a lot of SAML2 SSO integrations, I'm definitely going to put SAML2 in an enterprise tier. My sanity is not worth dealing with SAML2 for customers who are trying to get by with some $100/month subscription plan.

In fact, Raygun's policy (according to this list) sounds like something I would do: add support for a couple common ones like Google and Facebook, make all the other SSO setups require an Enterprise plan.

* note: I dealt mostly with higher-ed. Don't know if they're more or less competent compared with corporations.

If you have compliance requirements it’s always a cost saver vs vetting and legal work required.

If I need to use your SaaS’s identity system, you cannot afford to do business with me, because my company will bury you in red tape and liability.

I think “afford to pay” is different from “let us price gauge so high the customer rethinks whether they really need it”. Charging 3 or 5 times is highway robbery.
>that doesn’t mean it should be free for any reason other than I don’t want to pay for it

Not the thesis of the article, this is taking down a straw man. The actual article says this:

>If companies claim to “take your security seriously”, then SSO should be available as a feature that is either:

>1. part of the core product, or

>2. an optional paid extra for a reasonable delta, or

>3. attached to a price tier, but with a reasonably small gap between the non-SSO tier and SSO tiers.

>Many vendors charge 2x, 3x, or 4x the base product pricing for access to SSO, which disincentivizes its use and encourages poor security practices.

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
My employer actively promotes SSO to clients for the main product, but discourages it's use for internal applications.
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.

So security should be free? That kind of implies something about its worth that I might not think is the author's intention.
> 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?

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)

I’m not about to call you an idiot, but we’re (happy) users of Auth0 (with Duo MFA). After a short transition period, this provides a better user experience and greater security than our prior stance (a mix of direct ADFS and some other random in-app username/password systems).

$228/mo doesn’t even register. We probably spend a lot more for coffee in the office. (We’re much higher volume user than that, but the initial price point is just not something that would be a barrier.)

Ahh, probably cognitive bias and reading their target audience wrong then. Having been homeless and trying to support a partner this same last year, that price still really throws me for a loop (and tbh so does your office coffee budget a bit haha ).
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
Ohhh. I'm a bit slow; yeah for sure that makes a ton of sense then.
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.

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.
I'm interested by why you think this. In the scheme of costs of having employees, the software costs are very low.
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.

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.

In my experience SSO is one of the most expensive features to build but worse than that it’s one of the most expensive to operate.

Your system becomes hard dependent on a piece of infrastructure outside of your control, frequently provided by some bad IT vendor. Failures on their side are always blamed on you & you spend tons of resources debugging their problems.

I’ll buy that SSO is a core feature but that doesn’t change the economics of it. It needs to require higher prices.

"A website written by someone who doesn't understand enterprise pricing"
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?
What does the unit "u/m" mean?
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.

So companies should have a moral responsibility to give away security features for free ? There is certainly a cost incurred while implementing such fesutres.
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.
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.
Heh, the GitLab on-prem pricing note of "$4 per u/m²" looks like "4 dollars per user per square meter".