Live data from Hacker News

An admittedly wandering defense of the SSO tax

ssoready.com

91–99 of 99 posts

Re: An admittedly wandering defense of the SSO tax

#91
post #26

This is a good economics lesson but fails to address the actual issue people have with the SSO tax. It isn't about the concept of price discrimination, but price discrimination when it comes to security . You can charge extra for convenience features or other value-add features, sure, but the choice of login provider is something that should be table stakes for every person and every organization regardless of how bi…

Sure, but most SaaS support “SSO at home” in lower tiers via either Google idp or GitHub. So yes you’re locked into those vendors which kind of sucks but it’s not necessarily true that you have to give up security without forking over the “SSO tax”

I mean, no. If they supported BYOSSO then they wouldn’t be, by definition, charging an SSO tax. People are using the term when SSO as a concept is gated behind a paywall.

Re: An admittedly wandering defense of the SSO tax

#92
> We can’t live in a world with zero profit. And who should determine what reasonable profits might be?

The society under whose umbrella we operate.

> a bottle of water should not cost $8” while waiting to board a flight at SFO. It’s very natural for us to say things like that.

The problem is the bottle of water is only worth $8 in part because they keep you from bringing in drinks not because its especially valuable at that time and place.

It's the difference between actually creating value and exploiting people out of their money

Re: An admittedly wandering defense of the SSO tax

#93
post #3

This car with no seat belts, no airbags, and no ABS is just price discrimination! Strangely, no one seems interested in celebrating the implied discount for not having safety.

People today will still buy used cars without those features. You would force them to pay more? What if they can't? I wouldn't celebrate taking those cars away from people.

We effectively did tell them they can't by not allowing any vendors to ship a lower cost car without those features. This method of operation in the car industry is incredibly common and has probably saved hundreds of thousands of lives.

As far as the older cars without those features allowing them to age out has almost entirely worked.

Re: An admittedly wandering defense of the SSO tax

#94
post #26

This is a good economics lesson but fails to address the actual issue people have with the SSO tax. It isn't about the concept of price discrimination, but price discrimination when it comes to security . You can charge extra for convenience features or other value-add features, sure, but the choice of login provider is something that should be table stakes for every person and every organization regardless of how bi…

Exactly my thoughts. IMO it's analogous to SSL/TLS, which for the longest time was something you had to pay extra for at multiple levels. You had to get a dedicated IP for your service instead of being able to use shared hosting, you had to buy the certificate itself, and you had to have someone renew it and install the new certificate every now and then. Even from the user side there were web sites I remember where SSL access as a client was a premium feature as if it had a meaningful cost per use instead of just the cost to have it available at all.

This was long lamented in the security-focused parts of the internet but no significant movement happened until late 2010 when the Firesheep extension made sniffing unencrypted passwords or session keys accessible to the masses. Suddenly it wasn't just security nerds complaining about things that could easily be brushed off by higher-ups, it was a problem that anyone who could install a Firefox extension (which thanks to ad blocking and the general badness of could see with their own eyes

Almost overnight major services decided that they in fact were fully capable of offering encrypted services to everyone. Suddenly client and server applications, SSL/TLS libraries, etc. that had been ignoring SNI all started supporting it over the next year or two so you didn't need a dedicated IP per hostname anymore. The ISRG was formed and developed Let's Encrypt to solve the problem of having to pay for certs, and while they were at it took the opportunity to develop and enforce the use of ACME with short-lived certificates so automation was effectively mandatory.

In six years we went from there being a "SSL/TLS Tax", which every part of the process would defend as absolutely necessary costs, to it being freely available to all and automatically supported by a lot of major application and service platforms.

I look at the SSO Tax situation as being mostly comparable from the user side of things. The internet as a whole would benefit from wide support for SSO, but the demand to solve the problem is minimal because most of the people making the purchasing decisions don't care about the problem enough to make it a requirement.

There are definitely some valid points that have been made about support costs associated with SSO, especially with regards to supporting more than just a couple of big name identity providers, but I don't think most people would complain if a vendor limited their free/cheap tiers to those couple of big systems those clients are likely already using. If someone needs custom integration they get to pay enterprise prices, but if they just want to sign in with Google that should be accessible to all. The support costs should scale well with a good implementation, hypothetically if Google or Microsoft changes something that breaks your integration you only have to fix it once to solve issues for everyone using it, as opposed to private identity services where each tenant might need something slightly different.

Re: An admittedly wandering defense of the SSO tax

#95
Implementing SSO is a nightmare, particularly if customers want controls on their side.

My view is that you should use Cognito (simple) or Auth0 (simple but expensive) and build a self-setup page for it. Then if customers want it, it's on them to deal with configuring.

Oh, and push them all to OpenID because it's a lot less hassle than SAML.

If you're selling to big businesses (and you generally want to be), they'll pay for it anyway because this sort of security thing falls under various box ticking exercises for ISO certifications.

Re: An admittedly wandering defense of the SSO tax

#96
post #83

Earlier quoted context omitted.

Nobody understands SAML because it doesn’t really exist. It’s not so much a standard as a bag of standard parts from which a protocol can be assembled. It’s possible for two implementations to be fully compliant and yet incompatible. PS: the single most common developer error is assuming the SAML configuration is static and has a single certificate somewhere. The modern approach is to get all configuration from a met…

> Nobody understands SAML because it doesn’t really exist. It’s not so much a standard as a bag of standard parts from which a protocol can be assembled. It’s possible for two implementations to be fully compliant and yet incompatible. I die Not make this experience. The specs exist and are detailled. I'm Not convinced your Last sentence ist true.

To be fair, SAML 1.0 was much worse than SAML 2.0 at interoperability, but there are still "profiles" in 2.0: https://docs.oasis-open.org/security/saml/v2.0/saml-profiles...

Even within the same profile, I've seen some major incompatibilities. For example, some Microsoft products interpret XML signing ever so slightly differently to many other libraries, breaking the protocol. (From what I could tell, MS was interpreting the standard correctly, others weren't, they were just testing against each other.)

The biggest gripe I have about SAML is that it's one of "those" committee-designed standards that has an inner-platform effect of using it's own custom extensibility model on top of the eXtensible Markup Language (XML). It's like the bad database schemas that have one table with three or four columns holding all data because the developers couldn't be bothered to learn SQL.

So instead of just this:

    
        John Smith
        john.smith@test.com
    
You have this monstrosity:

    
          
            test
          
          
            test@example.com
          
          
            users
            examplerole1
          
    
I was just troubleshooting SAML issues yesterday, and the library used for that is about 750 KB of compiled bytecode. The source must be over 2 MB, not including also heavyweight dependencies like XML, XML Schema, and XML Signing. For something as trivial as "send me a token with some attributes and a signature" it's way, waaaaay overcooked.

Re: An admittedly wandering defense of the SSO tax

#97
It appears that many of the complaints in this thread are related to the complexities of SAML. I configure, manage, and troubleshoot many SSO configurations in my work but they are all OAuth2/OIDC based and find them really quite simple, easy to understand, and the RFC's a pleasure to read. Has anyone used both SAML and OIDC in their career and could comment on whether I avoided a difficult time in SSO with SAML, or am I just unaware of the difficulties because its what I regularly work with...

Re: An admittedly wandering defense of the SSO tax

#98

This a terrible defence. The reason there's a belief of an SSO tax is not that you have to pay more to get SSO, it's that companies use SSO to get you to pay for features no-one ever wanted but they did a lot of development on because they know you need SSO. And the gatekeeping of it behind sales people.

> features no-one ever wanted but they did a lot of development on because they know you need SSO. I’ve been around product development for 20+ years and I have NEVER seen a feature that “no-one ever wanted” get a lot of development resources. What I see a lot are features that a few huge customers want get those resources, and other people without that perspective write them off as useless. Meanwhile we’re closing 9…

Ad placement in software? Not many users appreciate it, and usually it's implemented to create value for the software company, not for the user. And yet it usually gets a lot of development resources.

Re: An admittedly wandering defense of the SSO tax

#99
post #26

This is a good economics lesson but fails to address the actual issue people have with the SSO tax. It isn't about the concept of price discrimination, but price discrimination when it comes to security . You can charge extra for convenience features or other value-add features, sure, but the choice of login provider is something that should be table stakes for every person and every organization regardless of how bi…

A customer who wants SSO is signaling that they are using this product in their business operations. I.e. they are making money from it. They aren't just learning it, or using it as a hobby. Therefore the product vendor is going to charge the customer at least some approximation of the value the customer is gaining from the product.

While generally true it's not a perfect signal. I would love to roll out SSO for my family off of my domain but can't because of the SSO tax. I realize power users like me are in the extreme minority
Post reply on HN