SSO should be table stakes
tuple.app
tuple.app
https://news.ycombinator.com/item?id=29892664
The SSO tax is obnoxious and it's obvious why everyone hates it, especially security professionals. But it has nothing to do with the cost of providing SSO features, and everything to do with market segmentation: by raising prices for large organizations (who reliably signal themselves by requiring SSO), you can cut or eliminate prices for small organizations. People who demand SSO are, essentially, flying business class, and paying for the back of the plane.
The process of enterprises procuring SaaS products has incentives that defy the common senses of a hacker.
For example, if you priced the exact same product at $200 vs $20,000 ACV, most enterprises wouldn't consider the $200 price-point because they would have a really hard time justifying the cost of their security & procurement team's time.
SAML SSO mostly exists on a plans page as an excuse for why the enterprise product costs 10-100x more than the base product.
As a founder, you'll feel some guilt about that initially, but it goes away after you've explained for the one-thousandth time that the question, "What anti-virus software is installed on your organizations Windows workstations" on the vendors security questionnaire is irrelevant because you run your company on a fleet of macOS and Linux workstations. They'll ignore you and move on to the next question, "what firewall configurations do you run on your physical office's network".
Wasn't the dream to log in once in the morning, and have your SSO token be valid for all systems all day? Is anyone out there successfully putting the "Single" in "Single Sign On"?
> Wasn't the dream to log in once in the morning, and have your SSO token be valid for all systems all day? Is anyone out there successfully putting the "Single" in "Single Sign On"?
I work for an identity provider that many of our clients use for SSO between applications, and it is absolutely possible to configure our solution to require 1 sign-in per day.
Also, the shameless self-promoter in me is required to let you know that we're hiring a Lead Web Developer: https://tuple.app/jobs/web-developer.
If our stance on the topic of SSO/security vs. profit appeals to you, please consider checking us out!
Slightly off-topic: If you really want folks to click through to your job ad, you can't go wrong if you mention that the salary range is ~$150k - $200k :-)
My question for you: do you think there are any other big, generic points of segmentation for SaaS consumers like SSO is? A few jump to mind:
* uptime SLAs (you mentioned this)
* data export/retention
* ???
I'm on record as saying that I think SSO will migrate down the value chain just like HTTPS did: https://twitter.com/mooreds/status/1481300034448760842 but am curious what will replace it.
This is especially true when the application in question offers strong authentication with no opt outs, which doesn't seem to be the case with Tuple -- I don't see a way to set a second factor, and the app happily let me register with 'password1234' as my password. Given their lack of strong authentication, I agree with SSO being part of the base subscription, for their own sake more than their customers'. I'd like to see them improve, revamp, or remove their direct login feature altogether.
What about removing access from tens of saas after a user left the company? Without SSO / centralized user management this gets skipped all the time.
But SSO eliminates an entire set of problems and increases the chances that someone will actually bother to worry about the other lifecycle elements. The chances that IT will invest in proper fully custom lifecycle automations are low. The reality is that it’ll be turned into a runbook and someone will take these steps manually.
SSO doesn’t magically solve that, but does let IT/Infosec focus on the lifecycle part. Also not universally true, but an app that doesn’t support SSO isn’t likely to support SCIM, and so now there’s a huge job ahead for the teams bringing a new tool into the org.
Setting aside security for a moment, the other outcome is that an increasing number of companies just won’t consider software that doesn’t have this support. I realize the discussion is about SSO-as-a-premium-feature, but when you start charging extra for something that is increasingly seen as a requirement for getting in the door, it leaves a bad taste in customer’s mouths. Better to just price it in.
I can’t fully agree with this, at least in an enterprise setting.
In an enterprise setting that has already standardized on <SSO solution>, any product that doesn’t support SSO will require a one-off set of processes for:
- Onboarding
- Password reset / recovery
- Offboarding
- Profile syncing
Each of these introduces yet another potential avenue for compromise, and at best, introduces more complexity into the environment - both for the IT team managing it, and for end-users. SCIM helps, but a product that doesn’t support SSO probably isn’t going to support SCIM.
Even if the app provides strong authentication with no opt-outs, there is now additional burden on end-users to be aware of potential app-specific phishing expeditions. IT cannot continue to say “the only real password recovery email looks like xyz”. There is now more burden on IT to ensure every non-SSO app has proper offboarding. Every non-SSO app is a misconfiguration away from being an attack vector for disgruntled former employees.
You may be right that SSO is primarily about convenience, but convenience isn’t just about the end-user and their login experience. Convenience can also be a security feature, if it means that the app can automatically benefit from some base level of security policy with little effort. Convenience becomes a security feature when the lack of that convenience leads to an equivalent lack of security - directly or indirectly - and this is often the case with apps that have no SSO support.
Apps that lack this support also tend to lack other advanced security settings that would be needed to make up for the lack of SSO.
(Former auth PM for a big SaaS, so my bias leans towards SSO-first, but this is what I saw when working with many large customers).
What’s your advice for small B2B startups looking into providing SSO for their customers?
Start with something like Keycloak and set things up manually for each customer? Is it even realistic to provide this in an automated / self-serve fashion with limited resources allocated to this?
Our pricing scales to be competitive with Okta even at higher volumes. The difference is ours is transparent and predictable, whereas Okta/Auth0's is opaque and requires you to negotiate with a sales rep every year. (Not a great experience...)
SAML/OIDC handle authentication.
OAuth is only part of the story and is not an alternative to SAML/OIDC.
[1] https://developer.okta.com/blog/2017/06/21/what-the-heck-is-...
But setting aside the inherent security issues, I think we're also talking about an orthogonal use case.
In the enterprise, customers use SSO to federate identity. Usually via a self-managed identity provider. Pseudo-auth with OAuth can work if the Identity Provider and the Application Server are one and the same, or if the Identity Provider is a ubiquitous service like Google/Facebook. In the latter case, this is the "Social Auth" we see on sites all over the web.
But in an enterprise setting, the security team isn't going to allow users to authenticate as their google identity.
So what about the app/ID server being one and the same? In this case, we're back to square one.
I build an App A, that provides a local user database. If I now add an OAuth server to facilitate pseudo-auth, the only thing I've accomplished is I've made it possible for client apps to hold tokens instead of the user's credentials. But that user's credentials are still local to the app, and not connected to the user's enterprise identity.
So while pseudo-auth with OAuth may be better than say, Basic Auth for 1st party clients, this doesn't help when the goal is to log in using the user's existing identity that lives outside of the app.
The reason "Login with Facebook/Google/Twitter/etc." work with very low friction is the ubiquity of those services. If I want to "Login with Haswell's Social Site" (or more realistically "<Org's> Identity Provider"), I'm SOL unless those sites support a standards-based auth flow (or provides extension points that allow me to implement my own.
- [0] http://www.thread-safe.com/2012/01/problem-with-oauth-for-au...
Products like this focus on "Auth as a Service", and they handle the heavy lifting while providing simple integration points for your product.
I'm not sure if I would classify LDAP as a middle ground though (rather, it's another tool in the toolbox) - it may be more challenging to implement as a software startup, and is often not viable depending on the customer environment.
Not where I'd invest development capacity in 2022.
I mention this in a sibling comment, but I think lumping SSO with lifecycle management for offboarding and profile syncinc is an example of convenience in lieu of security. You might be making an argument for SSO _and_ SCIM to be part of base subscription for enterprise software, and I wonder where does the line get drawn for what's tables takes. Are approval workflows required? What about anomaly detection? These features are not off the shelf commodities -- SSO might be closer to it, but SCIM and the other definitely aren't -- and making them table stakes raises the barrier to entry for every SaaS. Or, from a consumer perspective, if I'm a small operation that doesn't need that convenience, I'd rather not subsidize other customers that do when I get the base subscription.
> Former auth PM for a big SaaS
Then there's a good chance we've worked together :)
If we zoom out a bit more, the entire product is about convenience. The customer pays for the product because they have a problem/burden that justifies the purchase of a product. But customers usually buy a product for the things that are unique about it. SSO is not one of those things and is trending towards commoditization. The fact that it affords additional convenience doesn't necessarily mean customers are willing to pay for that.
SCIM is a bit more interesting, because it provides an abstraction layer over the things that are unique about a product. SCIM is also probably overkill for products with sufficiently simple offboarding needs.
> You might be making an argument for SSO _and_ SCIM to be part of base subscription for enterprise software, and I wonder where does the line get drawn for what's tables takes
SCIM hasn't reached the level of adoption (and customer expectation) that traditional forms of SSO have, and as a result I don't think it's in the table stakes conversation at this point. I think this will change over time if SCIM sees widespread adoption.
From a customer perspective, a product without SSO can be a non-starter. A product without SCIM just means some additional integration/automation will be needed, or at worst, a manual process will be implemented around offboarding.
> Then there's a good chance we've worked together :)
This particular world is definitely a small one, so maybe! ;)
At the same time, I can’t pay $2000 extra for every service just to be able to use SSO. News like this is very welcome.
- People still stored passwords on Slack channels, emails, Confluence, etc.
- People still used simple passwords such as "password".
- Literally nobody who wasn't already using a password manager started to use one.
In my opinion SSO, 2FA, etc. are absolutely needed at many places where people can't be trusted with following basic advice and training.
Plus I don’t think anyone on here is recommending infrastructure should be poorly configured. ;)
But IN GENERAL, properly configured SSO (heck, the defaults for most of the SSO providers) makes for a better user experience while increasing security.
I assume you offered one that was easy to use and supported and any cost paid for by the employer?
Let's take Tuple as an example. You put "Active user pricing" into Enterprise plan. Why is that not "table stakes"? It does not involve complex tech, and not charging inactive users seems like a fair thing to offer all your customers?
This blog post feels like a "beef marketing" play out of Basecamp's marketing book.
Almost every SaaS business I’ve run into allows you to SSO with providers like Google, Office365, Slack, and other common sources of identity.
If your company is paying for SAML through Okta, you can afford enterprise pricing.
The way I know is Okta’s UX is horrible and only enterprise scale companies would inflict that upon their employees.
Okta's list price starts about $7/user/mo - https://www.okta.com/pricing/ - That's not a huge sum. And in this increasing hybrid world, not uncommon for companies to be less than 25 employees and buying into SSO. Okta's also probably the most expensive of the major dedicated players in that space (like Ping, OneLogin, etc).
Now lets look at some end systems:
* https://slack.com/pricing -- Almost doubles in price to get SAML. $5.83 /user/mo increase.
* https://zoom.us/pricing -- $50/user/year increase (~$4.14/user/mo)
* https://www.atlassian.com/software/access/pricing -- $4/user/mo
A lot of other systems don't even publish their prices, like Smartsheet. But just two of those systems alone are more than the cost of Okta. And hardly any companies have only "2 or 3" systems to SAML.
So as a business you can get a SSO provider for reasonable cost, but end up paying many multiples more than the cost of the provider...to the services to get support. Is each individual service breaking the bank? No. But are they a problem for IT staffs to get budget cumulatively? Very much so.
It isn't clear to me if you are only looking for open-source solutions. If so, keycloak is your best bet. I've run into a smattering of others (Gluu, Ory, supertokens) but Keycloak is full featured and packagable as a container.
If you are okay with "free as in beer" solutions, FusionAuth has a community edition you can download[0]. There are a few limitations, primarily around support and advanced features[1], but no limits on number of SSO (SAML, OIDC) connections[2].
The license FAQ has more details[3].
0: https://fusionauth.io/download
1: https://fusionauth.io/pricing
2: https://fusionauth.io/docs/v1/tech/reference/limitations#wha...
If everyone used Okta, no problem. But then you get an Enterpise customer who’s using their own home grown SSO solution an we get to spend weeks debugging login issues.
We've had a couple painful SSO integrations (when they were home-grown, as you correctly point out), but we've pretty much got the rough edges sanded down now. I don't think we've had a tough one in a while.
It helped to publish some short docs on it: https://tuple.app/sso_setup
But you can support just 5ish SAML IDP's and get a large majority of the market and have effectively no ongoing support issues because its really well known (and well documented) how to set them up.
And I don't want to have to create a service account for the software to do things like searches: try to do the bind, and let the person in if it works. Anything else must be optional (all the world is not AD).
OAUTH requires a redirect URI [1] which presents challenges for vendors wanting to sell on-prem, because it demands the customer to set up DNS as well as TLS certificates obviously. This is an ongoing challenge for us because not all shops are wild about vendors dictating these requirements.
I'm very curious what other prem vendors do in this case, and what's the prem IT team's typical best case scenario here?
And what am I supposed to send the request to if I'm running OpenLDAP or Samba4 for accounts? If I'm running AD then there's a good chance I have Azure/cloud AD, so that's a possibility, but that could still take official IT approval.
How many 'shadow IT' operations will want to run some software but can't 'official' access to account system. How much effort would it be to go through official IT channels to get something inside of an organization? Will every team that wants to use the software be willing to go through a possibly Kafkaesque process? If they can just deploy a JAR or container and fiddle with some YAML to point to and LDAP server would that reduce friction? Do you think they'd want to deal with stand-alone in-app accounts versus leveraging their existing credentials? (And perhaps only deal with in-app groups.)
If a vendor wants implement something in addition to LDAP BIND they're welcome to, but the possibility of getting a simply yes/no decision for access using existing credentials gets rid of a lot of friction (and would make the auditors happy as well probably).
We could support LDAP instead of OAUTH, yes, but for the shops that want us to speak TLS and DNS, they still have some hassle.
Django Authentication system for example has a User object that allows different backends to feed into it:
* https://django-auth-ldap.readthedocs.io/
* https://django-oauth-toolkit.readthedocs.io/
* https://stackoverflow.com/questions/22668434/saml-with-djang...
Good luck with that. We have enterprise clients who want SSO, and if we won't implement it, they will--I guess through some sort of browser automation. In short, you price hike has to be less than their marginal cost of turning on their browser automation switch.
That said it depends on the criticality of the service you are providing. If customer data is involved, enterprise will fork over the dollars. If not, then yes you need to price it correctly or in practical terms include it as a freebie for the other "indispensable" features that they are really going for.
Historically SSO (especially SAML), Directory Sync, Audit logs, enhanced roles/permissions, etc. have always been something that only Enterprises needed. We think this is now getting commoditised and should start becoming available to all customers, a big reason why our core products are on an Apache 2.0 license and startups can use it for free.
A lot of these features also tie back to security and compliance (please bear with me, I know compliance is normally just a peacock dance and has nothing to do with true security but it is still necessary to do the dance). They definitely come with a cost to implement (even if the solution is bought from vendors like us), maintain and more importantly customer support costs.
- One way to make these features table stakes would be to include it in all plans but for instance limit SSO to the top 5 Identity Providers (Okta, Azure, OneLogin, PingIdentity and Duo), normally the ones with bespoke SSO implementations are usually enterprises in any case so you can still command a higher price point for them. - Another effective way is to say that RFPs/Security Questionnaires are only included in the Enterprise tier, the other tiers should be able to make do with a DPA and your InfoSec policy/ISO 27001/SOC2 docs. For enterprises this step is something they cannot skip, it's part of the procurement process for them. - But the best thing to do if possible would be to add some core features/enhancements to your product that are absolutely essential for enterprises.
This is the point sso.tax is trying to make as well, they want the SSO feature to be available to everyone without having to pay a large premium on the price (which is usually high for startups/SMBs to justify paying for).
Ultimately you have to have the right price segmentation and the reality is even the best companies struggle with being able to serve all segments effectively.
Auth0 and Okta for example, after you hit some magical thresholds force you into talking to sales who then try to upsell enterprise plans and most startups can't afford those price points and anything less than those price points does not move the needle for Auth0/Okta so they end up ignoring the lower segments.
Use-based pricing is my favorite pricing method, but your product has to be useful if you want to charge based on use. Most people don't have the guts to do it, because the "per user per month" is such an easy way to get money. If you go for use-based pricing, you have to make sure people actually use your thing, which is hard work!
If you’re at the point where employees x services is too big to do manually and then congrats you graduated to the “actually paying for the service tier.”
There’s no real way to skin, “the only real money is by charging many dollars to large enterprises and if we can’t easily price discriminate the thing we’re dropping is the subsidized free/startup tier.
But I understand the need to milk the badly managed companies.
There are plenty of other features that can be worth paying more for. Just look at GitHub Enterprise. The fact that the only way there is to get SSO is to pay 4.5x more is insane. But, as a GH Enterprise customer myself, there are plenty of other features (separate environments, more Action minutes, advanced code scanning options, etc.) that make GH Enterprise worth it.
The features of GH enterprise you listed are nice-to-haves, above a certain org size SSO is required.
I think we are disagreeing, because the point is that small orgs absolutely should not have to compromise on this basic security feature, and the end result is a less secure internet that is a detriment to everyone.
I do think hiding SSO behind "call us" is a pain however.
I do wonder how much of that money goes into subsidising the free tiers and paying (comparatively) enormous wages of developers to add features I don't really want.
I've seen probably ~10 companies financials that do this. It's ALL OVER THE PLACE. The reality is that the free doesn't two things: tests those new features on guinea pigs and lets you upsell to someone who has given you permission to do so.
There's no free lunch.
Fair. But wouldn't the opposite also hold true? The purchasers who say "what..I got pay $10/user/month extra for JUST SSO?"
> To integrate one is less than 100 lines of code.
Ugh not this again...
Let's use a simple example:
AcmeCo makes a widget and sells it for $50
WorldCo buys widget for $50 and uses it create $75 worth of services, thereby profiting $25.
AcmeCo has an opportunity to make up to charge up to $74.99 if they want, because WorldCo still profits. That, in its simplest terms, is what pricing on. value means.
Europe, Asia, or otherwise don't magically say "well that's not fair, you don't deserve higher profits". That's silly, so stop pretending thats the case outside of the US.
If we accept that service providers are going to price discriminate, then we accept that they are going to price discriminate on _some_ imperfect heuristic.
It seems to me that you have to argue
(A) Businesses should not price discriminate
Or
(B) price discrimination based on marginal features is okay but this particular feature (needing SSO) isn't very predictive
Or
(C) This particular feature might be predictive, but security is too important to be part of a willingness-to-pay heuristic, so it's unethical to use this particular feature in this way.
C seems like the argument a lot of people here are obliquely making.
At minimum I think it's reasonable to charge for SSO onboarding and maintenance on as as-needed basis.
The best happy medium I’ve found is allowing “sign in with google” for free and true SAML paid.
SSO isn't the problem. Proliferation of apps is the problem. SSO is just the glue that evidences the problem.
https://fidoalliance.org/fido2-2/fido2-web-authentication-we...
Apple just talked about how they’re supporting FIDO with the new MacOS and iOS.
FIDO was originally about ending phishing. With SMS or TOTP, if you give the SMS/TOTP code to a phishing site it can forward it to log in. FIDO is bound to a specific site, making it non-forwardable. Security no longer relies on users correctly identifying that they're on a invalid site.
Perhaps you are talking about the more recent push for passwordless FIDO [1]? Indeed the security argument for this is a lot more murky, and the cross-device portability tied to your browser-sync vendor looks a lot like Single Sign On.
However it's still not the same as SSO. SSO provides a single identity, but FIDO passwordless just shares a login credential, not the identity. You can log into two different sites with FIDO passwordless with different email addresses, with no way for the sites to know you are the same person. There's no "organization" that has the power to revoke your login (I mean perhaps Google can, but not your employer/school/whatever like in SSO).
[1] https://fidoalliance.org/apple-google-and-microsoft-commit-t...
In general yes, it'll be possible if Chrome/Android ends up supporting passkeys and then Google suspends your Chrome/Android syncing service. It'll still be good to have two passkeys on each service, but just on two different ecosystems, which still reduces the burden of needing to enroll every new device on every new service.
So, I may be completely uninformed here, but I don't see SSO as a good thing. I understand the advantages it has, but it gives an outside party the ability to restrict what your employees can do, should it so decide.
For example, we hear of Google banning people from accounts all of the time. Perhaps your company uses Google's SSO for all of its vendor accounts. If Google decided to ban the admin accounts of your SSO, all of your employees are now unable to work. Perhaps that happens during an outage caused by a DDoS (maybe the DDoS effects were why Google banned you). At that point, your employees can do nothing to bring your systems back online. If they can't, chances are you will go out of business if your revenue depends on your systems being online.
This seems like an enormous risk.
I'm no cryptographer, but here's my design of something to replace SSO: instead of each vendor supporting SSO, they support "certificate checks." When a user, your employee, logs on, the vendor contacts a pre-determined server, preferably controlled by you directly, for a certificate for the employee. Your server can either return one, cryptographically signed by your master key, of course, or refuse to return one.
If it returns one, and the signature is valid (maybe they expire after certain amount of time), then the vendor will let your employee on. If not, the vendor refuses access.
I believe that this system has the upside of SSO that access to all vendors for a particular employee can be revoked at any time by simply telling the server that you control to not return a certificate, but it also does not have the downside that centralized authentication for your business is controlled by someone else.
Of course, this also means that the employee cannot use one username and password for access to everything (unless they do it manually, of course; are you training your employees to not do that?). However, I think that that is actually an advantage because that single account sign on becomes a single point of failure. If that account is compromised, perhaps by phishing, the attacker now has access to all of the vendor accounts for that employee. Having separate username/password pairs for all of the accounts is much better (you are having your employees use password managers, right?).
Am I right? If not, why? What am I missing?
- It lets them tick a bunch of compliance related checkboxes
- The stats on average number of SaaS apps used in enterprises is something like 80 apparently, you can imagine the insanity of managing access to all these
- The single point of failure is never usually a big concern compared to the centralised access they get on the back of SSO