4 ms·

It’s not mentioned but I’m assuming that they built their own OIDC/OAuth backend and not use existing ones (eg okta, Auth0 etc). It would be interesting to kno

by pm90 7y ago

It’s not mentioned but I’m assuming that they built their own OIDC/OAuth backend and not use existing ones (eg okta, Auth0 etc). It would be interesting to know the details of how they’re doing authorization. It appears that it’s all or nothing but I might be mistaken.

YawningAngel 7y ago
Running an OAuth2 server isn't tremendously involved. There are good open-source projects like https://github.com/ory/hydra https://github.com/ory/hydra that are pretty easy to configure.
- inferiorhuman 7y ago
  Oh god, at megacorp we implemented our own OAuth2 stack. Much sadness ensued.
  - masonhensley 7y ago
    Been there, done that - wish it upon no one. If anyone ever brings up the idea of building out oauth or even vaguely user management, I try to point them to at least try a POC (Proof of Concept) with https://www.keycloak.org/ https://www.keycloak.org/ (Apache 2.0 License) or https://www.gluu.org/ https://www.gluu.org/ (MIT License) before they considering building.
    - corford 7y ago
      Another solution is OpenLDAP (or JumpCloud) at the root and then supporting software: OpenLDAP ├── PrivacyIDEA (TOTP/MFA with LDAP auth backend) ├──---└── SAML iDp (e.g. SimpleSAMLphp or Shibboleth) for SSO: AWS, Google, Github, Atlassian, Snowflake, Azure etc. ├── Dex (https://github.com/dexidp/dex) for anything that wants Oauth flow ├── Native LDAP for apps that support it (e.g. Metabase, Grafana) ├── Any other custom authT that supports LDAP as a backend OpenLDAP itself isn't for the faint hearted but I've had a lot of success with JumpCloud (and Okta also have an LDAP directory service... though starting price is high).
      - pm90 7y ago
        I don’t think anyone building a modern identity solution should base it on openldap. LDAP is amazing as an identity provider in a data center, but does not offer support for modern authentication methods like oath and oidc. As such, it’s not a very good base for creating your organizations identity. I’m happy to be proven wrong about this. I love open standards and protocols.
        corford 7y ago
        I think you've misunderstood my comment. LDAP gives you an extremely well supported back end from which to easily extend to virtually any form of authZ, including oauth.
        nulbyte 7y ago
        > LDAP is amazing as an identity provider in a data center, but does not offer support for modern authentication methods like oath and oidc. I don't think lack of support for OAuth is a problem here. OAuth is specifically designed to obtain access to an HTTP service[1], and OpenID Connect is specifically designed for OAuth. LDAP is not an HTTP service. [1]: https://tools.ietf.org/html/rfc6749 https://tools.ietf.org/html/rfc6749
meagar 7y ago
Hey, I worked on this project for ~2 years, though I'm no longer with Shopify. We started with Doorkeeper and gradually switched to building our own OAuth2/OIDC implementation over time, partially using glued together lower-level libraries like https://github.com/nov/openid_connect https://github.com/nov/openid_connect Edit: I forgot, I even have a few small commits to that last project from my time at Shopify: https://github.com/nov/openid_connect/commits?author=meagar https://github.com/nov/openid_connect/commits?author=meagar
- riffraff 7y ago
  So, did you have issues with doorkeeper that forced you to switch? Or was it just not fit for the problem you were trying to solve? I've used it a bit in the past and it worked fine, but I didn't really push it.

by pm90 7y ago

YawningAngel 7y ago

Running an OAuth2 server isn't tremendously involved. There are good open-source projects like https://github.com/ory/hydra https://github.com/ory/hydra that are pretty easy to configure.

inferiorhuman 7y ago
Oh god, at megacorp we implemented our own OAuth2 stack. Much sadness ensued.
- masonhensley 7y ago
  Been there, done that - wish it upon no one. If anyone ever brings up the idea of building out oauth or even vaguely user management, I try to point them to at least try a POC (Proof of Concept) with https://www.keycloak.org/ https://www.keycloak.org/ (Apache 2.0 License) or https://www.gluu.org/ https://www.gluu.org/ (MIT License) before they considering building.
  - corford 7y ago
    Another solution is OpenLDAP (or JumpCloud) at the root and then supporting software: OpenLDAP ├── PrivacyIDEA (TOTP/MFA with LDAP auth backend) ├──---└── SAML iDp (e.g. SimpleSAMLphp or Shibboleth) for SSO: AWS, Google, Github, Atlassian, Snowflake, Azure etc. ├── Dex (https://github.com/dexidp/dex) for anything that wants Oauth flow ├── Native LDAP for apps that support it (e.g. Metabase, Grafana) ├── Any other custom authT that supports LDAP as a backend OpenLDAP itself isn't for the faint hearted but I've had a lot of success with JumpCloud (and Okta also have an LDAP directory service... though starting price is high).
    - pm90 7y ago
      I don’t think anyone building a modern identity solution should base it on openldap. LDAP is amazing as an identity provider in a data center, but does not offer support for modern authentication methods like oath and oidc. As such, it’s not a very good base for creating your organizations identity. I’m happy to be proven wrong about this. I love open standards and protocols.
      - corford 7y ago
        I think you've misunderstood my comment. LDAP gives you an extremely well supported back end from which to easily extend to virtually any form of authZ, including oauth.
      - nulbyte 7y ago
        > LDAP is amazing as an identity provider in a data center, but does not offer support for modern authentication methods like oath and oidc. I don't think lack of support for OAuth is a problem here. OAuth is specifically designed to obtain access to an HTTP service[1], and OpenID Connect is specifically designed for OAuth. LDAP is not an HTTP service. [1]: https://tools.ietf.org/html/rfc6749 https://tools.ietf.org/html/rfc6749

meagar 7y ago

Hey, I worked on this project for ~2 years, though I'm no longer with Shopify. We started with Doorkeeper and gradually switched to building our own OAuth2/OIDC implementation over time, partially using glued together lower-level libraries like https://github.com/nov/openid_connect https://github.com/nov/openid_connect Edit: I forgot, I even have a few small commits to that last project from my time at Shopify: https://github.com/nov/openid_connect/commits?author=meagar https://github.com/nov/openid_connect/commits?author=meagar

riffraff 7y ago
So, did you have issues with doorkeeper that forced you to switch? Or was it just not fit for the problem you were trying to solve? I've used it a bit in the past and it worked fine, but I didn't really push it.