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.
> 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]:
It's a thorny problem, for sure.0: https://fusionauth.io/docs/get-started/core-concepts/users
> 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.