3 ms·

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, th

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

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