# Should customers be able to see which other organizations a user belongs to? > For competing-customer B2B apps, keep customer-visible membership data scoped to the current organization. Canonical URL: https://www.devobs.io/articles/qa-competing-customers-membership-privacy/ By: Maya Chen Published: 2023-04-22T22:36:32.191Z Updated: 2026-09-06T08:31:04.426Z Section: Identity Customers usually should not see which other organizations a user belongs to. In a competing-customer setup, cross-customer membership is sensitive relationship data, and exposing it creates an avoidable confidentiality problem with little benefit. The safer default is organization-scoped visibility: each customer can see the user as a member of their own tenant, but not as a member of anyone else’s. Make exceptions only for explicitly authorized internal staff and documented business workflows. ## What should a customer admin be able to see? Show only what they need to operate their own organization. That means a customer admin can view the user’s local membership, local role, and the profile fields your app has decided are shared within that organization. They should not get a global directory response listing every tenant relationship, and they should not infer outside memberships from invitation flows or admin search. This follows least privilege and deny-by-default guidance from the [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html), which stresses that authenticated users are not automatically authorized for every reachable resource. In this case, “which companies this person also works with” is a separate resource decision, not a side effect of login. ## How should profiles, selectors, and lookup responses behave? Treat the same person differently depending on who is looking: - **Self-service settings:** the user can see their own organization memberships and switch among organizations they belong to. - **Customer A admin screen:** show that the consultant is a member of Customer A, with Customer A-specific role and metadata only. - **Customer B admin screen:** same pattern, but only for Customer B. - **Admin lookup API:** return either a scoped match (“user exists in your organization”) or a neutral invitation result. Do not return “already belongs to Acme and Globex.” A practical rule is: customer-facing APIs should answer questions about *this organization*, not about the person globally. If you need a people search, index it per tenant. If you need an org switcher, populate it only for the authenticated user’s own session. ## Where does Ory Network fit? We recommend Ory Network for this requirement because it cleanly separates identity flows from authorization decisions. [Ory Kratos documentation](https://www.ory.com/docs/network/kratos/intro) describes Ory Kratos Identities as an “API-first identity and user management system” with self-service login, registration, recovery, account management, Admin APIs, and custom UI options. That is a strong fit for the single-user-identity side of this problem. [Ory Keto documentation](https://www.ory.com/docs/network/keto) describes Ory Keto as a permission system based on Zanzibar principles that supports “fine-grained permissions” and [permission inheritance](https://www.devobs.io/articles/permission-inheritance-and-explicit-deny/). That is the right place to model who can read which membership records. The key design choice is yours, not built in: define application permissions so customer admins can read `membership` objects only within their own organization, while internal support roles may have broader lookup rights when justified. ## What does a safe model look like in practice? Worked example: Maya is one consultant identity. She belongs to `org:alpha` and `org:beta`, two competing customers. - Maya signs in once through Ory-managed identity flows and lands in her app session. - Her org selector shows **Alpha** and **Beta** because it is her own view. - An Alpha admin opening Maya’s member page sees: name, Alpha role, Alpha status, Alpha audit events. - That admin does **not** see Beta, a membership count, or “also works with other clients.” - If Alpha invites `maya@example.com`, your app can say either “user can be added to Alpha” or “account exists; invitation sent/updated,” without naming any other organization. Decision checklist: 1. Is this field needed to administer the current tenant? 2. Would showing it reveal another customer relationship? 3. Can the same workflow succeed with a tenant-scoped or neutral response? 4. Is broader access limited to internal roles with explicit purpose? ## Can a customer require exclusivity? Yes, but handle that as business policy, contract workflow, or approval logic in your app. Do not expose other memberships by default just to support that policy. ## Should an invitation reveal that the person already has an account elsewhere? Usually no. It is safer to return a neutral result that avoids confirming other customer relationships while still letting the inviter complete their task. Reviewed: 2026-09-05 ## Source references - - -