[pm90]

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]

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

[inferiorhuman]

Oh god, at megacorp we implemented our own OAuth2 stack. Much sadness ensued.

[masonhensley]

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/ (Apache 2.0 License) or https://www.gluu.org/ (MIT License) before they considering building.

[corford]

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]

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.

[nulbyte]

> 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

[corford]

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.

[meagar]

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

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

[riffraff]

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.