4 ms·

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

by 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

by konha 4y ago

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