Hacker News Reader

Comment by satyrnein | Hacker News Reader

From the docs:

Users exclusively belong to Organizations; every User belongs to exactly one Organization.

But I also see a screenshot where, after login, the User has to choose an organization or to create a new one. It seems to me that you support Users and Organizations in a many-to-many relationship, is that correct?

At my work, we landed on the terminology of Users, Memberships, and Accounts to describe this (a User can have Memberships to multiple Accounts, an Account can have multiple Members, etc). As a result, you don't "delete a user", you "revoke a membership".

View on HN

(I'm the other cofounder of Tesseral).

Yeah, this is a line I wrote and could probably improve the clarity on. It's worth distinguishing the Tesseral concept of a User from the sense in which we might colloquially refer to a user. Some other people call the equivalent of a Tesseral User a Member or something similar.

An individual human being who wants to log in can be represented by multiple Users in Tesseral, each of which belongs to exactly one Organization.

That is, there's support for a given person with a given email address to participate in different workspaces, but each workspace will have a different instance of a User.

That feels needlessly confusing and not a great way to handle large orgs. Datadog does a similar thing—I need to completely switch contexts to start working in a separate organization and there's absolutely no way to open tabs from two orgs side by side. Not to mention, any link to a dashboard or alert will fail until I go and select the right org from the dropdown (and if I don't know what org the link is in from context, I have no way to find it).

I don't think new auth services should encourage this pattern and I highly recommend that you remove this restriction as soon as possible before it becomes even more baked in. Your downstream services should have access to all of the orgs a user belongs to right from the beginning, using a comma-separated list or multi-value headers or something similar. Don't shard user IDs in this way.

I don’t think this is necessarily true. You don’t want org1 to have access to the data that user x has access to in org2.

But when I authenticate my common support agents instead of the customers themselves, I do want them to have access to everything.

I don’t think anyone has yet managed to make this easy.

> You don’t want org1 to have access to the data that user x has access to in org2

Of course not—I'm not sure why you'd think I mean that?

I'm just saying that if I open a link to `https://datadog.com/alert/12389` and `https://datadog.com/alert/12500` and the alerts are for different orgs, my auth cookies should be able to tell that I, as user X, have access to both orgs without having to "switch contexts" or re-auth.

> But when I authenticate my common support agents instead of the customers themselves, I do want them to have access to everything.

> I don’t think anyone has yet managed to make this easy.

We have a few recommendations for this (I work for FusionAuth, a different auth server). From our doc[0]:

    Have users reset their password every time they need access to a different tenant.
    Use a passwordless login option like a magic link or passkey.
    Set up or use an administrative identity server, such as a second instance of FusionAuth, Google GSuite, or Azure AD/Microsoft Entra, and have these users log in using that.
    Put all admin users in one FusionAuth tenant, create an application in that tenant, and set up an OIDC Identity Provider for applications in other tenants to delegate to that application.

It's a thorny problem, for sure.

0: https://fusionauth.io/docs/get-started/core-concepts/users

It's possible to have multiple Datadog orgs open in the same browser context by having an admin from your account enable custom subdomains (https://docs.datadoghq.com/account_management/multi_organiza...).

It would also help with links routing to the correct org:

> If you are a member of multiple organizations, custom sub-domains help you identify the source of an alert or notification. Also, they can immediately switch you to the organization associated with the sub-domain.

Wow, that's super helpful, thanks.

However, that doesn't change my opinion that one-org-per-session and one-org-per-user is a terrible way to design an auth/auth system and Tesseral—a library/service that is trying to Get Auth Right—shouldn't design such a limitation into their system from the beginning

I think FusionAuth does something similar. They have a global user, and uses the notion of tenants / application registrations (which I think is comparable to a Tesseral Organization) to segment the same user.

Then you can define applications (which are mapped 1:1 to tenants) where a user has a registration entry against that application, where a user can be referenced by their global user id, or application-specific user id.

Applications are OAuth2 applications (meaning a dedicated client id / secret), so we only create a single application and tenant, and maintain organization segmentation on our own application / db side instead.

(We're paying customers of FusionAuth. Anyone from FusionAuth, feel free to correct me.)

"An individual human being who wants to log in can be represented by multiple Users in Tesseral, each of which belongs to exactly one Organization."

This will be extremely confusing. You should simplify it and just keep the concept of User as we usually do. A user should have access to 1 or more organizations. That's it. You should rethink this otherwise it will be too confusing.

But isn't this kind of like saying your logins to Blizzard and Activision should actually be the same underlying user? Doesn't make sense, and becomes an authz nightmare, imo.

I think the logic is to differentiate the "identity" from a "user"

One identity can have multiple users (one for each organization) At the same time, a user can have multiple identities. (e.g. username/password, Google oAuth, SAML etc.)

Here is a usecase.

Auth backend for an online accounting software.

An "admin" user creates orgs. Invites 3 other users.

Then there are orgs with multiple admins, multiple users, single user is member of multiple orgs by invite.

Like we have GitHub orgs.

The other terms that gets thrown around for this is “Workspace” and some sort of “Visitor”, “Guest”, or “Membership” relationship, or a “we create a copy and assign it to the new Organization” strategy. The past three places I’ve worked have done something akin to this. Usually after they guess about how Google Docs/Google Workspace functions based on observed behavior.

Reply on news.ycombinator.com