News and analysis
A portal for several companies: signing in does not establish data access
Auth0, Neon and GitLab illustrate three isolation layers: organization context, storage boundaries and permission checks inside the application.
An employee has signed in, but which company are they acting for? Could they open another company’s order through a direct link? As a B2B product grows, these questions arise before elaborate SSO configuration. Recent Auth0 and GitLab publications, considered alongside a September Neon architecture article, help distinguish three layers of the decision.
Establish the organization context
On 9 October, Auth0 described Organizations, with membership, identity-provider connections, metadata and roles scoped to an organization. Its FlowGrid and Acme examples are explicitly fictional. They explain a scenario without demonstrating a customer implementation or outcome.
For your own portal, establish which organization owns each record. One person can work for several companies with different rights in each. The selected organization must therefore accompany an action, rather than remain a name in the header. Permission to read an order in one company should not become permission to edit every company’s orders.
Storage separation addresses another layer
In its 14 September account of LuBot’s architecture, Neon describes a database per tenant, with shared accounts and billing in Supabase. This is earlier background for the comparison, not an October announcement.
Separate databases can establish an explicit storage boundary, but the application still selects the database to use. A routing mistake or excessive administrator access does not disappear merely because storage is separated. Make that decision alongside requirements for maintenance, recovery and customer-account administration.
Check authorization after authentication
On 5 October, GitLab discussed an internal Django application that began serving two audiences. login_required alone was insufficient to restrict access to its separate modules. Hiding a menu item does not replace server-side authorization either.
Taken together, these articles suggest a practical acceptance condition: the system knows the user, the active organization and permission for the specific action. Those facts must consistently determine the data selected. The identity provider, database design and application code operate at different layers; none substitutes for the others.
For acceptance testing, create two sample companies and a user with different roles in each. Try a direct URL to another company’s record, change an identifier in an API request, switch company context and execute a previously queued job. Then remove the user’s access and repeat the actions. Agree the expected outcome beforehand, including a clear refusal.
Our guide to business rules and permissions helps frame the checks. The archived API design discusses access models, rather than adoption of these new products. When developing a customer portal, discuss organizations, roles and data boundaries before adding another integration.