We're currently starting to work on ORY Hive (project name wip) which is going to be a fully functional identity management service (user registration, login, social sign in, password reset, MFA, ...) sort of along the lines of Auth0 or AWS Cognito, but as an OSS solution.

As part of that service, we will add connectivity adapters for generic OAuth2/OIDC providers as well as (probably) LDAP/AD and SAML integration.

We're still in prototyping phase (building a good API here is really tricky because no open standards exist to our knowledge for this) and it will take some time. But hopefully, it will be something many people can build on!

And thank you so much for the positive feedback :)

That sounds awesome! I'd really like to see organizational management, i.e., users in orgs. It is something most B2B SaaS apps have to do, and they tend to do it differently and often very poorly. Maybe it is out of the scope of ORY Hive, but I think it would be really useful. I'm thinking it would tie into an RBAC system to give users different permissions within orgs (member, admin, owner, etc.).

There are two main patterns for B2B apps:

- One org per user, like G Suite. A user is a member of a single org, to be a member of another org requires another user account. This creates a challenge when it is a system where someone might be a member of multiple orgs, because it requires logging in as multiple users and having cookies that can handle that.

- One user in many orgs, like GitHub. A users "owns" their user account, and is invited to one or more orgs. This makes working in multiple orgs easier, but can create challenges for companies that want to enforce things within their org, like SSO or 2FA. It also creates issues with routing of notifications (you want work notifications going to work email), and identity of users within a company (an org admin may have trouble identifying users if they aren't tied to company emails).

An ecosystem like ORY obviously can't alleviate all the issues, but maybe it can help with some of them, like org membership and org friendly cookies.

Good use cases, we in fact are looking at multi-tenancy or "realms" but have not progressed very far here as it can get quite complicated. One major issue with true multi-tenancy is obviously data isolation, so usually you don't want data to "bleed" from tenant a to tenant b (think G Suite) whereas in other systems it's not truly a tenant but more of a business entity that shares users.

I think in the end it boils down to what we can solve in a generic manner and what we can let developers solve for themselves. The distinction between the two use cases is definitely something we'll take a closer look at and include in our design decisions, so this won't be an afterthought but something built into the architecture!

Thank you for your constructive feedback!

Thanks for the info, looking forward to your new project!