13 ms·

SSO should be table stakes

123 points by charlieirish 4y ago

deepakprab 4y ago
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.
cratermoon 4y ago
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.
mffap 4y ago
https://sso.tax/ https://sso.tax/ a lot of companies put SSO behind a paywall. Not a fan of making users pay for basic security features.
- jrockway 4y ago
  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.
  - r00fus 4y ago
    Which is why a lot of services (ie, commercial APIs) rely on # of hits/uses as a measure.
    - jrockway 4y ago
      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!
      - r00fus 4y ago
        It mainly happens with B2B (e.g. forex rate services like xignite or Bloomberg).
- lmkg 4y ago
  I think I read somewhere that many companies use "needs SSO" as a proxy for "is Enterprise customer and can pay Enterprise rates."
sebk 4y ago
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.
- konha 4y ago
  > Single sign-on, however, is a convenience feature, not necesarily a security feature. 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.
  - sebk 4y ago
    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.
    - hnlmorg 4y ago
      The context of this discussion isn’t about using Google or Facebook style SSO, it’s about SaaS supporting enterprise identity providers.
    - haswell 4y ago
      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.
mkl95 4y ago
At my previous gig I observed a few worrying things that were not fixed with security training: - 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.
- powerslacker 4y ago
  SSO/2FA should be required. It's less burdensome on the end users than expecting training to fix their bad behavior.
  - ironmagma 4y ago
    If that’s true, why even bother with the training?
    - powerslacker 4y ago
      I wouldn't.
- coredog64 4y ago
  Counterpoint: Poorly configured SSO devolves to “sign-on every single time”, which will then put you back in that same situation.
  - hnlmorg 4y ago
    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. ;)
  - ShakataGaNai 4y ago
    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.
throwaway490583 4y ago
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.
n4jm4 4y ago
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.
softfalcon 4y ago
Correct me if I’m wrong, but isn’t this why Apple, Microsoft, and Google are all pushing for WebAuthN/FIDO login schemes? https://fidoalliance.org/fido2-2/fido2-web-authentication-webauthn/ https://fidoalliance.org/fido2-2/fido2-web-authentication-we... Apple just talked about how they’re supporting FIDO with the new MacOS and iOS.
- advisedwang 4y ago
  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). [1] https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins/ https://fidoalliance.org/apple-google-and-microsoft-commit-t...
  - judge2020 4y ago
    > (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.
r00k 4y ago
Hi folks! Author here. Big fan of this topic, and happy to answer any questions you might have about it. 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 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!
- ayewo 4y ago
  Hi Ben! 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 :-)
  - ezekg 4y ago
    Also changing the job description to software engineer, not web developer, may help. Quite a few colleagues wouldn't want to downgrade their title. :)
- mooreds 4y ago
  Thanks for putting the salary range in the webdev role! (I asked you to do so on Twitter :) ). 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 https://twitter.com/mooreds/status/1481300034448760842 but am curious what will replace it.
throw0101a 4y ago
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).
- imglorp 4y ago
  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? 1. https://www.oauth.com/oauth2-servers/redirect-uris/ https://www.oauth.com/oauth2-servers/redirect-uris/
  - throw0101a 4y ago
    > 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).
api 4y ago
As usually implemented it gives "root on the entire universe" to large tech companies, mainly Google and Microsoft for most sites and apps.
nsxwolf 4y ago
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"?
- bedatadriven 4y ago
  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.
  - mc32 4y ago
    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.
- Aeolun 4y ago
  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.
- dexwiz 4y ago
  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.
- coldacid 4y ago
  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).
rubixdude 4y ago
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.
- r00k 4y ago
  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. It helped to publish some short docs on it: https://tuple.app/sso_setup https://tuple.app/sso_setup
- ShakataGaNai 4y ago
  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.
utdiscant 4y ago
I disagree. There are entire companies built around making it simpler to implement and manage SSO (like https://workos.com/ 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.
corrral 4y ago
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?
- scrollaway 4y ago
  You can self-host keycloak. It's … curiously not that hard, though the documentation is a jungle.
  - Aeolun 4y ago
    Hosting it is simple, setting it up is a nightmare (though marginally easier than PingFederate, which is truly monstrous)
- mooreds 4y ago
  Disclosure: I work for FusionAuth. 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 https://fusionauth.io/download 1: https://fusionauth.io/pricing https://fusionauth.io/pricing 2: https://fusionauth.io/docs/v1/tech/reference/limitations#whats-not-limited https://fusionauth.io/docs/v1/tech/reference/limitations#wha... 3: https://fusionauth.io/license-faq#3 https://fusionauth.io/license-faq#3
jacobsenscott 4y ago
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.
funstuff007 4y ago
> 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.
- jiveturkey 4y ago
  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.
flappyeagle 4y ago
This is a straw man argument. Blog posts like this leave a bad taste in my mouth because of how transparently misleading they are. 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.
- judge2020 4y ago
  https://sso.tax/ https://sso.tax/
  - flappyeagle 4y ago
    This website is… plain wrong? The first company listed is Airtable, which offers google SSO on their free tier.
- ShakataGaNai 4y ago
  > 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/ 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 https://slack.com/pricing -- Almost doubles in price to get SAML. $5.83 /user/mo increase. * https://zoom.us/pricing https://zoom.us/pricing -- $50/user/year increase (~$4.14/user/mo) * https://www.atlassian.com/software/access/pricing 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.
randomuxx 4y ago
SSO is horrible. AMA
- deepakprab 4y ago
  Which bits specifically? :)
dj_mc_merlin 4y ago
The fact that they use the "SSO Wall of Shame" (https://sso.tax/ https://sso.tax/) as a way to sell you on the idea is funny and counterintuitive.
tptacek 4y ago
I'm repeating myself here and apologize for it, but I think it's worth keeping this on your mind in these discussions: https://news.ycombinator.com/item?id=29892664 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.
- froggertoaster 4y ago
  Completely agree with your take.
- bradgessler 4y ago
  If I could upvote this 1000 times I would. 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".
  - singron 4y ago
    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.
godman_8 4y ago
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.
froggertoaster 4y ago
I'm seeing some posts reference https://sso.tax/ 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.
gavinhoward 4y ago
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?). Am I right? If not, why? What am I missing?
- deepakprab 4y ago
  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
spacemanmatt 4y ago
I deal with a lot of security domains every day. It would be 10-100x more without SSO. SSO isn't the problem. Proliferation of apps is the problem. SSO is just the glue that evidences the problem.
- deepakprab 4y ago
  I agree, something like 80 SaaS apps on average per enterprise apparently. I like to call it Death by SaaS! ;)

123 points by charlieirish 4y ago

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.

cratermoon 4y ago

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.

mffap 4y ago

https://sso.tax/ https://sso.tax/ a lot of companies put SSO behind a paywall. Not a fan of making users pay for basic security features.

jrockway 4y ago
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.
- r00fus 4y ago
  Which is why a lot of services (ie, commercial APIs) rely on # of hits/uses as a measure.
  - jrockway 4y ago
    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!
    - r00fus 4y ago
      It mainly happens with B2B (e.g. forex rate services like xignite or Bloomberg).
lmkg 4y ago
I think I read somewhere that many companies use "needs SSO" as a proxy for "is Enterprise customer and can pay Enterprise rates."

sebk 4y ago

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.

konha 4y ago
> Single sign-on, however, is a convenience feature, not necesarily a security feature. 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.
- sebk 4y ago
  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.
  - hnlmorg 4y ago
    The context of this discussion isn’t about using Google or Facebook style SSO, it’s about SaaS supporting enterprise identity providers.
  - haswell 4y ago
    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.

mkl95 4y ago

At my previous gig I observed a few worrying things that were not fixed with security training: - 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.

powerslacker 4y ago
SSO/2FA should be required. It's less burdensome on the end users than expecting training to fix their bad behavior.
- ironmagma 4y ago
  If that’s true, why even bother with the training?
  - powerslacker 4y ago
    I wouldn't.
coredog64 4y ago
Counterpoint: Poorly configured SSO devolves to “sign-on every single time”, which will then put you back in that same situation.
- hnlmorg 4y ago
  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. ;)
- ShakataGaNai 4y ago
  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.

throwaway490583 4y ago

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.

n4jm4 4y ago

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.

softfalcon 4y ago

Correct me if I’m wrong, but isn’t this why Apple, Microsoft, and Google are all pushing for WebAuthN/FIDO login schemes? https://fidoalliance.org/fido2-2/fido2-web-authentication-webauthn/ https://fidoalliance.org/fido2-2/fido2-web-authentication-we... Apple just talked about how they’re supporting FIDO with the new MacOS and iOS.

advisedwang 4y ago
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). [1] https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins/ https://fidoalliance.org/apple-google-and-microsoft-commit-t...
- judge2020 4y ago
  > (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.

r00k 4y ago

Hi folks! Author here. Big fan of this topic, and happy to answer any questions you might have about it. 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 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!

ayewo 4y ago
Hi Ben! 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 :-)
- ezekg 4y ago
  Also changing the job description to software engineer, not web developer, may help. Quite a few colleagues wouldn't want to downgrade their title. :)
mooreds 4y ago
Thanks for putting the salary range in the webdev role! (I asked you to do so on Twitter :) ). 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 https://twitter.com/mooreds/status/1481300034448760842 but am curious what will replace it.

throw0101a 4y ago

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

imglorp 4y ago
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? 1. https://www.oauth.com/oauth2-servers/redirect-uris/ https://www.oauth.com/oauth2-servers/redirect-uris/
- throw0101a 4y ago
  > 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).

api 4y ago

As usually implemented it gives "root on the entire universe" to large tech companies, mainly Google and Microsoft for most sites and apps.

nsxwolf 4y ago

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

bedatadriven 4y ago
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.
- mc32 4y ago
  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.
Aeolun 4y ago
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.
dexwiz 4y ago
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.
coldacid 4y ago
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).

rubixdude 4y ago

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.

r00k 4y ago
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. It helped to publish some short docs on it: https://tuple.app/sso_setup https://tuple.app/sso_setup
ShakataGaNai 4y ago
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.

utdiscant 4y ago

I disagree. There are entire companies built around making it simpler to implement and manage SSO (like https://workos.com/ 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.

corrral 4y ago

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?

scrollaway 4y ago
You can self-host keycloak. It's … curiously not that hard, though the documentation is a jungle.
- Aeolun 4y ago
  Hosting it is simple, setting it up is a nightmare (though marginally easier than PingFederate, which is truly monstrous)
mooreds 4y ago
Disclosure: I work for FusionAuth. 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 https://fusionauth.io/download 1: https://fusionauth.io/pricing https://fusionauth.io/pricing 2: https://fusionauth.io/docs/v1/tech/reference/limitations#whats-not-limited https://fusionauth.io/docs/v1/tech/reference/limitations#wha... 3: https://fusionauth.io/license-faq#3 https://fusionauth.io/license-faq#3

jacobsenscott 4y ago

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.

funstuff007 4y ago

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

jiveturkey 4y ago
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.

flappyeagle 4y ago

This is a straw man argument. Blog posts like this leave a bad taste in my mouth because of how transparently misleading they are. 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.

judge2020 4y ago
https://sso.tax/ https://sso.tax/
- flappyeagle 4y ago
  This website is… plain wrong? The first company listed is Airtable, which offers google SSO on their free tier.
ShakataGaNai 4y ago
> 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/ 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 https://slack.com/pricing -- Almost doubles in price to get SAML. $5.83 /user/mo increase. * https://zoom.us/pricing https://zoom.us/pricing -- $50/user/year increase (~$4.14/user/mo) * https://www.atlassian.com/software/access/pricing 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.

randomuxx 4y ago

SSO is horrible. AMA

deepakprab 4y ago
Which bits specifically? :)

dj_mc_merlin 4y ago

The fact that they use the "SSO Wall of Shame" (https://sso.tax/ https://sso.tax/) as a way to sell you on the idea is funny and counterintuitive.

tptacek 4y ago

I'm repeating myself here and apologize for it, but I think it's worth keeping this on your mind in these discussions: https://news.ycombinator.com/item?id=29892664 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.

froggertoaster 4y ago
Completely agree with your take.
bradgessler 4y ago
If I could upvote this 1000 times I would. 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".
- singron 4y ago
  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.

godman_8 4y ago

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.

froggertoaster 4y ago

I'm seeing some posts reference https://sso.tax/ 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.

gavinhoward 4y ago

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?). Am I right? If not, why? What am I missing?

deepakprab 4y ago
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

spacemanmatt 4y ago

I deal with a lot of security domains every day. It would be 10-100x more without SSO. SSO isn't the problem. Proliferation of apps is the problem. SSO is just the glue that evidences the problem.

deepakprab 4y ago
I agree, something like 80 SaaS apps on average per enterprise apparently. I like to call it Death by SaaS! ;)