4 ms·

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

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

konha 4y ago
> Former auth PM for a big SaaS 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?
- catsonthestreet 4y ago
  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/ https://docs.propelauth.com/
- rsstack 4y ago
  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.
  - grinich 4y ago
    WorkOS founder here. 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...)
- infamia 4y ago
  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?
  - haswell 4y ago
    OAuth handles authorization. SAML/OIDC handle authentication. OAuth is only part of the story and is not an alternative to SAML/OIDC.
    - infamia 4y ago
      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? [1] https://developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth#pseudo-authentication-with-oauth-20 https://developer.okta.com/blog/2017/06/21/what-the-heck-is-...
      - haswell 4y ago
        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. - [0] http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html http://www.thread-safe.com/2012/01/problem-with-oauth-for-au...
- haswell 4y ago
  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.
- caloique 4y ago
baq 4y ago
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...
- Aeolun 4y ago
  SSO may be about 100x harder than LDAP. I dunno, I thought it was this nasty enterprisey thing, and then I found that it’s actually super lightweight.
- haswell 4y ago
  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.
sebk 4y ago
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 :)
- haswell 4y ago
  > 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! ;)
Aeolun 4y ago
Having now used SSO, I don’t think I ever want to go back to managing permissions separately for every individual user. 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.

konha 4y ago

> Former auth PM for a big SaaS 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?

catsonthestreet 4y ago
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/ https://docs.propelauth.com/
rsstack 4y ago
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.
- grinich 4y ago
  WorkOS founder here. 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...)
infamia 4y ago
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?
- haswell 4y ago
  OAuth handles authorization. SAML/OIDC handle authentication. OAuth is only part of the story and is not an alternative to SAML/OIDC.
  - infamia 4y ago
    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? [1] https://developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth#pseudo-authentication-with-oauth-20 https://developer.okta.com/blog/2017/06/21/what-the-heck-is-...
    - haswell 4y ago
      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. - [0] http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html http://www.thread-safe.com/2012/01/problem-with-oauth-for-au...
haswell 4y ago
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.
caloique 4y ago

baq 4y ago

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

Aeolun 4y ago
SSO may be about 100x harder than LDAP. I dunno, I thought it was this nasty enterprisey thing, and then I found that it’s actually super lightweight.
haswell 4y ago
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.

sebk 4y ago

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

haswell 4y ago
> 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! ;)

Aeolun 4y ago

Having now used SSO, I don’t think I ever want to go back to managing permissions separately for every individual user. 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.