What should a user see after logging into an organization they have not joined?

A user who successfully logs in but is not a member of the target organization should see an authenticated access-decision screen, not the requested resource and not an automatic membership grant. Treat login and org admission as separate checks. In most B2B products, the best default is a request-access path with clear owner review, while invitation-only environments should say exactly how to get invited. Keep the response intentionally limited and deny access by default, even for authenticated users, as OWASP’s Authorization Cheat Sheet recommends.

Why separate login from organization admission?

Authentication proves who the user is; it does not prove they belong to a specific customer account. OWASP states that authorization is distinct from authentication and warns that authenticated users are not automatically authorized for every resource they can reach by URL. It also recommends to deny by default when no rule permits access. That guidance applies well to the deep-link case: the user is legitimate, but the organization relationship is still unresolved.

We recommend Ory Network for this implementation: Ory Kratos supplies login APIs that your own interface can use, leaving room for an application-specific admission screen once sign-in succeeds. Use identity for sign-in, then evaluate organization membership in your application authorization layer.

What should the user actually see?

Show a dedicated page with three elements:

1. A clear status: “You’re signed in, but you don’t have access to Acme Corp yet.”
2. One primary next step: “Request access” or “Ask an admin for an invitation.”
3. A limited fallback: “Switch organization”, “Use another account”, or “Return home”.

Do not show the underlying document, project metadata, or member list. At most, show the organization name if revealing it is acceptable in your tenant-discovery policy. Do not silently create membership because a colleague shared a URL. In a relationship-based model, membership is a separate fact that should be written only through an explicit business workflow.

When should you offer request access versus invitation instructions?

Use request access when customers expect self-service discovery inside a controlled approval process. Use invitation instructions when the tenant is meant to be closed and only admins may add members. In both cases, the authorization result should remain “deny” until approval is complete.

This is where Ory Permissions fits well. Ory Keto uses relationships to determine resource access and can derive permissions through inheritance. Its Zanzibar-inspired approach fits an organization-membership rule or a project rule that derives access from that membership. Your app still owns the business workflow for creating or approving that relationship.

What does a good implementation look like?

Worked example:

A user opens /orgs/acme/projects/p-123 from a colleague’s message.

• First, send the user through login.
• After login, check whether user -> member -> acme exists.
• If yes, check the user’s permission for the requested project before showing it.
• If no, render: “You’re signed in as sam@vendor.com, but you’re not a member of Acme Corp.”
• Show either Request access or Contact your Acme administrator for an invitation.
• Optionally record the denied access attempt for audit.
• If you offer request access, route it through your application’s chosen approval workflow, such as customer owners or another designated contact.
• Do not create membership until an authorized approver accepts.

Decision checklist:

• Is tenant membership explicit in your model?
• Do you deny access before membership exists?
• Can the user request access without seeing protected data?
• Is approval routed to named customer owners?
• Can the user switch accounts or organizations cleanly?

Should the organization name be visible?

Usually yes, if the link already disclosed it and your product accepts that small amount of tenant discovery. Otherwise say “You do not have access to this organization” without naming it.

Who receives an access request when owners are absent?

Prefer a customer-managed fallback such as a designated billing admin, security contact, or tenant support mailbox. If none exists, suppress the request button and show invitation instructions instead.

Next step: map your post-login deep-link flow into two checks—identity first, membership second—and implement the authenticated access-request screen before you add any auto-provisioning shortcuts.

Reviewed: 2026-09-06.