Managing Sectors

Your SpartanAuth account has a tenant root sector — the default sector you land in when you log in to the dashboard. From that root you create sub-sectors, one for each application you want to authenticate.

A sector is an isolated namespace: users, credentials, security settings, OAuth providers, allowed origins, and API keys all belong to one sector. End-user login (the login widget) always targets a single sector ID.

Tenant root vs sub-sectors

Aspect	Tenant root	Sub-sector
What it is	The default sector for your organization	An additional sector you create for one app
Who administers it	Tenant root admins	Admins of that sector, plus tenant root admins
Use it for an app?	Possible, not recommended	Recommended — one sub-sector per app
Dashboard login	Your organization slug (for example /login/acme)	Each sub-sector has its own slug if you want a dedicated login URL

Create a sub-sector for each application you host. The tenant root can authenticate an app, but sharing it across products mixes users, CORS origins, OAuth clients, and API keys. Sub-sectors keep each app’s users and settings separate while you still manage everything from the tenant root dashboard.

Tenant root admins can:

• Create, edit, and delete sub-sectors (the tenant root itself cannot be deleted)
• Invite users and manage profiles in any sector in the organization
• Create API keys on the tenant root (those keys can administer every sector) or on a single sub-sector (scoped to that app)

Sub-sector admins can only manage that sub-sector.

Creating a sub-sector

1. Log in to the dashboard with your tenant root account.
2. Open Sectors.
3. Under New sector, enter a name (e.g. “Production app”) and a slug (URL-safe login identifier, lowercase letters, numbers, and hyphens).
4. Optionally set Domain and Allowed Origins (you can add these later).
5. Submit. Copy the new Sector ID (UUID) — that is what the login widget’s sector attribute uses.

One sub-sector per app

Use separate sub-sectors for production, staging, and each product. Point each app’s widget at that sub-sector’s ID, not the tenant root ID.

The slug is fixed after create. It is used in dashboard login URLs (https://dashboard.spartanauth.com/login/{slug}).

Switching sectors in the dashboard

The sidebar sector dropdown switches context. Users, security settings, OAuth, and API keys always apply to the selected sector. Tenant root admins can switch into any sub-sector; sub-sector admins only see their own.

Sector settings

Domain and allowed origins

The Domain field sets the primary origin for the app that uses this sector. SpartanAuth uses this for:

• CORS — only requests from allowed origins can call the API from a browser
• Email links — password reset and magic link URLs

Allowed Origins adds extra CORS origins (e.g. https://staging.myapp.com, http://localhost:5173 for local development). Configure origins on the sub-sector that app uses, not only on the tenant root.

Required for browser-based login

SpartanAuth enforces per-sector origin validation on every authentication request — password login, OTP, passkeys, OAuth, and more. A request from a browser origin that is not listed in that sector’s Domain or Allowed Origins is rejected.

If you skip this on the sub-sector your widget targets, login on that site will fail.

Common origins to add:

• Production: https://myapp.com (or whatever you set as Domain)
• Staging: https://staging.myapp.com
• Local dev: http://localhost:5173

Tip

Add http://localhost:5173 (or your local dev port) to Allowed Origins while developing. Remove it before going to production.

Self sign-up

When Self Sign-Up is enabled on a sector, new users can register via <spartan-login>. When disabled, users must be invited. This is per sector — you can allow self sign-up on a public app and keep it off on an internal tool.

Security settings

Per-sector options include:

• Required MFA
• Password policy
• Session / access token lifetime
• WebAuthn RP ID and origins (passkeys)

Configure these on the sub-sector your users actually log into.

Deleting a sector

Deleting a sub-sector is permanent and removes profiles, credentials, and settings in that sector. The tenant root sector cannot be deleted.

When you delete a sub-sector, also remove its users if you no longer need those accounts, and stop sending that Sector ID from your app.

Next steps

• User management — invite users into the correct sector
• OAuth providers — social login per sector
• API keys — tenant root keys vs sub-sector keys
• Login widget — pass the sub-sector ID into sector