I agree with the premise of the article, but I would not focus solely on SAML. Support Oauth and OIDC, if for no other reason than easier GDPR compliance.
It cuts both ways. While SSO is a basic security feature (and improves usability and reduces support burden), it also makes account sharing more difficult. Users on the low end plan definitely like account sharing; create a google group as the email, put the password in the shared vault, now the thing is $5/month instead of $30k a year.
You have to be a really useful service to price things this way. "Per user per month" means that people that don't use your software are still paying for it, which I guess is the best kind of user -- not adding any database rows, not burning any CPU, and not opening any support tickets. Good work if you can get it!
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!
I mean the alternative is the fat wallet tax. Is your company more than 20 employees or do you have more than 1M revenue, here’s a 500% price increase.
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.
Having more than 20 employees or 1M revenues isn’t going to make an expensive product more attractive. I have been quoted twice this year at prices where hiring competent people would be a lot cheaper than purchasing the SSO option.
But I understand the need to milk the badly managed companies.
On the buying side we always used to joke that we could hire someone who’s entire job would be updating peoples passwords for less than they were charging and still have 30hrs/wk of an engineer. Sadly no one volunteers to be the password bitch.
No, it's not. SSO is basically a feature that should be used with all companies size > 1 (and even with size = 1, but not as critical there). It simply should not be considered an "enterprise" feature anymore - it should be considered a basic, lowest-level product requirement.
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.
You know we’re not disagreeing right? Is it simultaneously true SSO should be used by everyone at all company sides and that small companies will absolutely take an 80% discount to not have it while large orgs will pay full price.
The features of GH enterprise you listed are nice-to-haves, above a certain org size SSO is required.
> that small companies will absolutely take an 80% discount to not have it while large orgs will pay full price
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.
My SO is the owner-operator of an SCorp currently adjusting the business to hire W-2 #1. As the consulting CIO I'm doing everything I can to keep it on 1 SSO.
Counterpoint - SaaS software pricing is hilariously underpriced at the current levels for the value it typically brings, that even SMBs should be paying the "enterprise rate" or at least some bump in price.
I do think hiding SSO behind "call us" is a pain however.
Personally, I think even the cheaper plans are overpriced some of the time, considering real resource usage and comparing against software licenses in the past.
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.
> how much of that money goes into subsidising the free tiers
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.
I think what people despise most about it is that SSO is sold as an enterprise feature. That would be ok if it was sold separately. But often SSO comes bundled with a lot of overpriced garbage in some enterprise agreement. Github is a prime example of this.
Explain to me exactly what a "fair price" is? Value is simple.
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.
The fact that a few people without deep pockets need SSO doesn't invalidate the whole enterprise.
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.
As much as people wish that they can get SSO for free, I don't think it's realistic for many companies. There are a lot of different SSO standards out there, and even among the most common type (SAML2) there are many different SP and IDP implementations that you have to interface with to make SSO work properly. Then there are issues around attribute syncing, patching XML vulnerabilities on your implementation (which seem to occur regularly), dealing with customers updating or patching their own implementations, homebake obscurities in implementations for things like NameID and attribute, and myriad other complications.
At minimum I think it's reasonable to charge for SSO onboarding and maintenance on as as-needed basis.
From a security engineering perspective I think strong authentication should be table stakes, and the proliferation of WebAuthn is a good starting point. For most enterprise companies it also likely makes sense from a risk management perspective. Single sign-on, however, is a convenience feature, not necesarily a security feature. And as such, I think it's acceptable for it to be an add on subscription.
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.
Relying on severing SSO access for this purpose is not enough. Those SaaS can be running processes that don't require an online user, or could support non-SSO API keys, or could still be taking up license seats. SSO in general is not a substitute for the full identity management lifecycle, protocols like SCIM are. I also believe these fall squarely in the convenience arena, but I also know that convenience and security are not orthogonal.
Agree that SSO isn’t enough by itself. Every app should have a full user lifecycle which involves more than just “Set user to inactive”.
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.
You can do that without SSO/SAML/whatever? As GP said this is not a security feature. It doesn't solve any of the security issues mentioned and it does not guarantee that the other side is implementing it correctly.
You can but it’s more work to build and results in infrastructure that has more places where things can go wrong. SSO is the standard (and, in my opinion, “correct”) way to manage identities across otherwise unconnected systems.
> Single sign-on, however, is a convenience feature, not necesarily a security feature.
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?
Okta, WorkOS, etc. offer easy (<1 week of work) implementation of fully self-service SSO. WorkOS pricing is very predictable and easy to offload to the customer, Okta are cheaper for larger numbers of customers.
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...)
How about implementing OAuth2 and then restricting account creation per domain/per tenant? For example, if your only two customers owns foo.com and bar.com, then restrict account creation to those two domains (assuming they're in one tenant together). There are lots of mature OAuth2 libraries, but the selection for SAML, ADFS, etc isn't nearly as good. You'll get the benefit of not storing passwords on your server and complying with whatever two-factor requirements the customer has, while avoiding the complexities of SAML, ADFS, etc. I'm curious if anyone has tried this approach and if so, did your customers's security departments sign off?
Thank you for the reminder! Based on my (very) limited knowledge, OAuth2 can still be used for so-called "pseudo-authentication" [1]. I'm not saying it is as good as SAML/OIDC, but those technologies are a major pain to implement and support for a small team. Pseudo-authentication seems like a good "bang for the buck" tradeoff. A more refined version of my question might be, "Is pseudo-authentication good enough to get past most security teams until you can scale up to SAML/OIDC?" I'm sure it likely isn't good enough for highly regulated industries (or Fortune 100 companies) that have prescriptive compliance regulations, but maybe it is good enough to get going in less rigid circumstances?
This post [0] provides a pretty good overview of the issues/pitfalls.
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.
Thanks for the very helpful, detailed reply. I think I've uncovered where my mental disconnect is. The industry I'm focused on often uses Google Workspaces as their enterprise SSO provider. I guess I had assumed that Microsoft offered something similar that could be used for pseudo-authentication, but I see that's frequently not the case. Thanks again!
I agree with the sibling comment re: Okta, WorkOS, etc. I was going to mention that products like Auth0 (now part of Okta) have some great options for this. I'm a couple years out of the space now, but I'm sure new products in the same category are emerging.
Products like this focus on "Auth as a Service", and they handle the heavy lifting while providing simple integration points for your product.
We created PropelAuth specifically for B2B startups. A lot of our competitors focus on individual users but we offer Organizations or Groups as a concept - meaning user invitations to an organization, roles scoped to that organization, etc. We're also completely self-service: https://docs.propelauth.com/
there's a middle ground between SSO and in-application user profiles - LDAP - though the state of support for it is usually abysmal: community open source projects don't support it because nobody cares enough and enterprise open source free tier products don't support it because it's an enterprise feature, so it's in the 'contact us' price bucket. it's probably worth it for the security alone, but what a PITA...
LDAP is in the "SSO family", but definitely brings with it a lot of challenges. Chief among those is binding over the open Internet if you're a cloud app. It's surprising just how many orgs are running unencrypted LDAP, which makes those environments unfit for authenticating apps outside of the company network.
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 don't disagree, but fundamentally, you're talking about burden for IT operators. The opposite of burden is convenience, and that's fine to be charged for, in my book. An app implementing strong authentication might not offer a phishable password reset email, but rather have your password reset by an operator out of band, which is again, a burden.
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 :)
> The opposite of burden is convenience, and that's fine to be charged for, in my book.
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! ;)
It doesn’t put you in the same situation. You’re still more secure than the former situation while also being unnecessarily more annoying to your users.
Plus I don’t think anyone on here is recommending infrastructure should be poorly configured. ;)
100% true. Poorly configured anything puts you into a terrible situation. If you setup a firewall and do a DENY ALL or ALLOW ALL blindly, you're going to have a bad time.
But IN GENERAL, properly configured SSO (heck, the defaults for most of the SSO providers) makes for a better user experience while increasing security.
Sounds like you needed a change management officer or compliance responsible, or similar. They would know how to get people to see the benefits of security and keeping to process (without being pushy)
I used to like watching Tuple, but the founder of Tuple has, in my opinion, become increasingly obsessed with money and what him and Tuple are able to do with it. From how he bragged about and marketed his $200k Stripe Capital loan ("in this economy?!"), to talking about overpaying engineers "because we can", to saying $25/mo is a rounding error for individuals (re: ngrok's pricing change). I'm not a fan of this behavior, and this blog post echoes the same: he has money and wants everybody to know it. It's a bad look, at least to me (fellow founder here using a throwaway). The majority of us are going to stick to using SSO as a way to charge enterprise customers more.
Reuse the session across applications. Min 24 hour expiration. The more times the user is forced to reauth, the higher the chances of a keylogger or over the shoulder attack successfully retrieving passwords. Also, more time is spent relogging into apps rather than getting things done.
Not really, webauthn/fido and SSO are orthogonal (you an have one without the other, and you can have both).
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).
> (I mean perhaps Google can, but not your employer/school/whatever like in SSO).
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.
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 :-)
As a sysadmin, I simply want on-prem software to be able to take the username entered, create an LDAP DN, and try to do a simple LDAP BIND attempt against the server:port of my choice.
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).
What is the expectation for on-prem software which uses OAUTH SSO?
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?
> What is the expectation for on-prem software which uses OAUTH SSO?
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).
These are all exactly the right questions and challenges we are encountering, and we have no good answers. In all cases, customer IT would prefer vendors did not give them more work and risk.
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.
Just to be clear: I'm asking for LDAP to be one possible choice. If an installation wants to use LDAP BIND they can use that, or if the want to use SAML they could use that, or OATH. But not at the same time: you get to choose one.
Django Authentication system for example has a User object that allows different backends to feed into it:
Man, I hate hate hate seeing the SSO portal 30 times a day, reaching for my phone to answer the popup every time. Which sometimes gets eaten by "Focus Mode" on my iPhone, or randomly goes to my watch and I have to look at both.
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'm not sure about the apps you're using, but our SaaS app sends users to Azure AD for example to authenticate via OpenID Connect and in 90% of the cases they are instantly directed back because they are already logged in.
It depends, some apps might be configured to require auth before taking you to the app. It may depend on compliance, or some company policy. Or if there is an SLO app that invalidates login sessions.
I’m fairly certain this works great for all systems that allow big bad enterprise to control what you do (Windows and IE, but Chrome is getting there too). Using FF on a Mac apparently makes it really hard to do automatic sign-on.
I have used a few SSO providers and never had this. I usually log into the portal once and then everything else resolve via redirects without interaction the rest of the day. Maybe I have to click confirm. This sounds like bad configuration on your ITs side of things.
Very likely it's your SSO vendor or IT department to blame for this (and in the latter case, probably due to policies they have to enforce but they aren't allowed to control).
Yes, plenty of places do this successfully. You either have some very aggressive cookie blocking or your IT has it setup this way in some misguided strict way.
On top of that, it’s called “two” factor authentication, not “phone” factor authentication. Why can I not simply use another computer or YubiKey to sign in, it has to be a phone? So annoying.
Shouldn't need another computer either. The extra security is having that one computer you use all the time participating on the login. If it's the one you are using, there is no reason at all to require another.
It's a configuration option, so it is in control of your IT staff. I'm not sure if there are security risks/compliance requirements specifying such a short SSO session duration (20 min?), but may be worth asking.
> 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.
I have the same frustration at current $BIG_CORP employer. It's maddening to think how much productivity must be lost by 100s of engineers being interrupted many times a day by this! Granted, I know nothing about how it is implemented, but I struggle to comprehend why this is necessary - the SSO client knows I authenticated literally minutes go from this device...how is that not sufficient verification!?
It's like that smart home post from a few days ago. The dream is that lights, heating and entertainment automatically turn on and off and adjust throughout the day. The reality is that someone in the house has to become the IT department, troubleshooting issues all the time. The reality is just way more work than the dream.
I wonder if the author discussed this with his support team? The reason my company charges for SSO is then increased support cost.
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.
I sit next to our support "team" pretty frequently :)
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.
Most sites have a preset for the major identity providers, Okta, Microsoft, OneLogin, etc. The ones who want to be nice will also have a generic "SAML" option allowing connections to just about anything - but that's when the home grown solution pain shows up.
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.
I disagree. There are entire companies built around making it simpler to implement and manage SSO (like https://workos.com/ which we use) - it is time consuming to support. Enterprise pricing will always be about finding some way to gate enterprise users into a more expensive plans.
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.
Decent place to ask I guess: what's the state-of-the-art for self-hosted SSO providers for a company that does a lot of self-hosting of open-source solutions? Like, if you're not relying on 3rd-party support for this, aren't using a cloud provider's proprietary solutions, et c., how do you do it in 2022?
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].
SSO is a disaster and needs a lot of support, no matter how good your SSO implementation is. I think that's why a lot of companies charge for it. We don't charge extra for it, but the reality is it ups our support burden.
> I recommend you create an enterprise tier, put SSO in it, and charge 2-5x your normal pricing
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.
Provisioning is more important, not the SSO per se. If your enterprise clients are willing and able to do some kind of relatively hokey workaround, they are not really enterprise. At enterprise scale (let's call that 2500+ employees), this isn't feasible. Even at 1000 it's pretty borderline.
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.
> If your company is paying for SAML through Okta, you can afford enterprise pricing.
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).
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.
I didn’t say you can pay for enterprise pricing because okta is expensive monetarily. I said it’s because oktas UX is terrible and only enterprise companies would force that on their employees.
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".
It would be awesome if SOC2 wasn't a joke and you could expect customers to accept that instead of answering endless superficial questionnaires. Then you could charge $5000 per questionnaire if they still really wanted it.
I mean at $35/user month it better include SSO. That's insanely expensive for the limited scope of this service. I'd rather buy Jetbrains at $32.45/mo (after annual and 3 years of membership) and get a full suite of IDEs including remote pair programming that's compatible on macOS, Windows, and Linux.
I'm seeing some posts reference https://sso.tax/ - as a SaaS product manager, it should be a great reference for you as it's basically a showcasing of successful SaaS products that properly segment markets.
tl;dr: SSO seems like a big risk to me, from being a single point of failure, and I think we could use signed certificates instead.
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?).
You have to look at it from the perspective of the Enterprise and you'll see that everything you list as risks is exactly what helps them mitigate their other critical risks:
- Lets them centralise access, provisioning and de-provisioning becomes simpler
- 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
Disclaimer: I am the co-founder of BoxyHQ, an open-source alternative to WorkOS.
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.
128 comments
[ 3.3 ms ] story [ 173 ms ] threadUse-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.
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?
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.
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.
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?
1. https://www.oauth.com/oauth2-servers/redirect-uris/
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...
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.
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.
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.
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...
3: https://fusionauth.io/license-faq#3
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.
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.
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".
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
SSO isn't the problem. Proliferation of apps is the problem. SSO is just the glue that evidences the problem.
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.