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”
An admittedly wandering defense of the SSO tax
91–99 of 99 posts
Re: An admittedly wandering defense of the SSO tax
#92The 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
#93This 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.
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
#94This 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…
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
#95My 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
#96Earlier 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.
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
#97Re: An admittedly wandering defense of the SSO tax
#98This 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…
Re: An admittedly wandering defense of the SSO tax
#99This 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.