Demo tenant
Issuer URL for the public OpenIssuer demo and OAuth clients.
https://demo.openissuer.com/issuerDocumentation
Integrate apps with tenant-scoped OIDC.
OpenIssuer exposes a standard OAuth2 and OpenID Connect issuer per tenant host. Applications use normal OIDC client settings while OpenIssuer handles tenant resolution, users, roles, organizations, and OAuth client management.
NextAuth callback format
Register the callback URL that matches the app host, base path, and provider id.
https://your-app.example.com/api/auth/callback/myauthDemo admin
Admin portal for creating and inspecting demo OAuth clients.
https://demo.admin.openissuer.comScopes
The demo client requests the standard OpenID Connect scopes.
openid profileIntegration flow
- Choose the tenant issuer URL for the customer or environment.
- Register an OAuth client in that tenant admin portal.
- Add the application callback URL to the client registration.
- Configure the app with issuer, client id, client secret, and scopes.
- Start the authorization code flow with openid and profile scopes.
NextAuth quickstart
Use the maintained example client to validate an OpenIssuer tenant from OAuth client registration through token and session inspection.
- Create an OAuth client in the tenant admin portal.
- Register the callback URL ending in /api/auth/callback/myauth.
- Configure the issuer, client id, client secret, and NextAuth secret.
- Deploy the app and verify the issuer and tenant claims in the session.
Admin portals
Tenant admins use the admin portal to manage OAuth clients, users, organizations, roles, and default organization access.
Deployment model
OpenIssuer supports both a shared multi-tenant deployment and a dedicated deployment for a business or entity. Both use standard host-based OAuth2 and OIDC issuers; the difference is where application workloads and service databases run.
Shared multi-tenant
Use this model when tenants can share service capacity and a common release lifecycle. Tenant-specific issuer databases and policies preserve logical boundaries without duplicating the platform stack.
Dedicated deployment
Use this model when a business needs independent rollouts, quotas, backups, network policies, or stronger namespace-level isolation. The tenant receives its own services and databases inside the Kubernetes cluster.