Multi-tenancy model

NamoID has three layers, each with a specific isolation purpose: tenants, projects, and environments.

Tenant              ← governance + membership boundary
├── Platform keys    ← tenant-wide automation credentials
└── Project         ← one product surface; one issuer family
    ├── Environment: test   ← test users, test credentials
    └── Environment: live   ← real users, live credentials

Tenants

The governance and membership boundary. Your team owns a tenant, and every other resource hangs off it. All tenant-scoped data is filtered by tenant scope — a user or client in one tenant can never see another tenant's data.

Tenants have a membership limit: a member can create one tenant and be invited to a small number of others. Invitations are managed from the tenant's members page.

Tenants also own platform keys (namoid_platform_sk_…). These are server-side automation credentials for setup scripts, CLIs, CI jobs, agency automation, and AI agents that configure NamoID resources across projects in the tenant.

Projects

A project is a logical product surface — a web app, a mobile app, an API. Each project contains environments, and each environment owns its applications (OAuth/OIDC clients), auth keys, webhooks, users, and audit stream. Projects within the same tenant are isolated from each other: granting scopes to one project's application does not grant them to another, and each project has its own consent state.

Environments

Inside a project, every resource is scoped to an environment, Stripe-style:

• test — isolated test users and test credentials.
• live — your real users and live credentials.

Environments are fully isolated: separate users, separate applications, separate auth keys, separate OTP budgets, and a separate issuer. A test credential cannot authenticate a production user, and vice versa. Credentials encode their environment in a visible prefix segment so you can tell at a glance which environment a key belongs to (see Environments).

Platform keys are the exception: they are tenant-scoped, do not include test or live in the prefix, and target a project/environment through the API route or request body.

How this maps to URLs

Resource	Pattern
Hosted login	https://<slug>.id.namoid.in/oauth/authorize
Discovery	https://<slug>.id.namoid.in/.well-known/openid-configuration
Dashboard	https://console.namoid.in/tenants/<tenant-id>/projects/<project-id>
Public API	https://api.namoid.in/v1/...

Each environment advertises its own issuer URL. You can also bring a custom domain (e.g. auth.yourcompany.com) per environment — once verified, its discovery document is served with that issuer. See Hosted login.

The Users panel

Because users belong to an environment, the dashboard's Users tab lists everyone who has consented to the selected environment's applications — with their verified state, first/last sign-in, and which applications they've connected. This is the authoritative view of your end users per environment.