Tenant issuer hosts
Issuer metadata, login, token issuance, and claims are resolved for the current host.
Architecture
Host-based multi-tenancy for OAuth2 and OIDC.
OpenIssuer resolves the tenant from the incoming host, loads that tenant's policy and authorization data, and returns tenant-scoped tokens. The same flow works whether the tenant uses shared services or a dedicated namespace.
Incoming requestHost resolutionTenant issuerScoped tokens
Admin management
Admins manage organizations, users, roles, OAuth clients, and default organization behavior.
Passkey MFA
Users can enroll passkeys and complete MFA during the authorization flow.
Choose the deployment boundary that fits your organization
OpenIssuer supports two ways to serve multiple organizations. Start with logical tenant isolation on a shared application stack, or give a business its own application and database stack when independent operations matter.
Shared multi-tenant
Each tenant gets its own issuer hostname, authorization data, OAuth clients, and policies. Tenants share the application services and service databases, keeping operations and cost low while preserving logical boundaries.
business.example.com → shared stack
Dedicated deployment
A business or entity gets a complete copy of the OpenIssuer services and databases in its own Kubernetes namespace. It shares only cluster-level infrastructure such as the Gateway, TLS, and operators, while gaining independent rollouts, quotas, backups, and namespace policy boundaries.
business.example.com → business namespace
One platform, both models
The models can coexist. A platform can keep evaluation and smaller customers on the shared stack while placing a regulated, high-volume, or operationally independent business on a dedicated deployment.
See both models in the OpenIssuer deployment
The running platform uses both patterns. These examples show how a logical tenant and a dedicated namespace can share the same cluster while keeping their operational boundaries clear.
Main namespace · logical tenants
Platform, Business 1, Free, and Demo use the shared services inmain. Each has its own issuer host and authorization database.
Dedicated namespace · complete stack
The dedicated tenant runs its own gateway-facing services and PostgreSQL databases in the dedicated-tenant namespace.
Add logical tenants inside a dedicated deployment
A dedicated namespace can still host more than one logical tenant. Add tenant entries to its catalog, then assign each issuer and admin hostname to its own authorization database. The application stack and service databases remain dedicated to that namespace.
{
"deploymentModel": "dedicated-namespace",
"namespace": "dedicated-tenant",
"tenants": [
{
"name": "business1",
"issuerHost": "business1.example.com",
"adminHost": "business1.admin.example.com",
"authorizationDatabase": "business1auth"
},
{
"name": "demo",
"issuerHost": "demo.example.com",
"adminHost": "demo.admin.example.com",
"authorizationDatabase": "demoauth"
}
]
}This pattern gives a business a dedicated operational boundary while allowing its brands, environments, or subsidiaries to remain separate logical issuers. Keep credentials in the approved secret workflow; the catalog contains configuration, not passwords.