Members vs end users
Every tenant in AuthSec has two distinct kinds of users. Get the distinction in your head once and the admin UI suddenly makes sense.
Members are operators
The people who run your tenant. They register Applications, write authz policy, approve OAuth clients, review audit logs, suspend abusive end users.
- Small, finite set — you can list them all on one screen.
- Lifecycle: invited → active → suspended → left.
- Managed under Settings → Team.
- Types:
owner,admin,member,contractor,service_operator,readonly_auditor. These are lifecycle labels, not RBAC roles. Anownerstill gets their actual permissions through a role binding.
End users are consumers
The people who use your Applications. Anyone who connects an AI client to your MCP server, signs into your web app, or grants a workload access to your APIs.
- Potentially huge — 10k, 100k, more.
- Created lazily, on the first OAuth consent.
- Managed under End Users (the default workspace in the admin UI).
- A tenant can:
- Suspend an end user — every token they hold against your Applications stops working. Their identity elsewhere is untouched.
- Set a plan tier (
free,pro, custom). Plan tiers map to role bindings via your billing policy. - Override rate limits per user.
End users do not appear in your Team list. They were never invited; they showed up through the OAuth flow.
Why the split matters
The most common modeling mistake when building auth for a public product is treating end users like members — manually inviting every signup, giving them admin-style entries in a teams list. Works for ten users, collapses at a thousand.
A solo dev launching a public MCP server can have 100,000 end users with a tenant whose Team list contains exactly one person: the owner.
| Aspect | Tenant member | End user |
|---|---|---|
| Created by | Invite, SCIM, signup-as-owner | OAuth consent flow |
| How many | Tens | Thousands+ |
| Admin surface | Settings → Team | End Users |
| Bulk-manageable | No (individual) | Yes (paginated, filterable, bulk actions) |
| Suspension scope | Loses all admin access | Loses access only to this tenant |
| Identity ownership | The tenant tracks them | The user owns it (Phase D) |
| Default RBAC | Admin-tier roles via bindings | Plan-tier roles via bindings |
A single human can be both — for different tenants
One person can be:
- The owner of their own tenant (
alex-tools). - A contractor member of a client's tenant (
acme-corp). - An end user of a public provider they personally use (
data-tools-cloud).
That's one identity, two memberships, one end-user state. The OAuth flow keeps the three concerns isolated; the admin UI surfaces them separately for each tenant they belong to.
Suspension is the cheapest lever
When you need to cut off access right now — leaked credentials, an abusive consumer, an offboarded teammate — use the status flip, not a binding rewrite. Set status to suspended and the membership precheck blocks every binding the user holds on the next introspection.
It's instant, reversible, and survives policy edits.
Related
- Groups and role bindings — how to grant access to many users at once
- Managing members — the operator-facing workflow
- Managing end users — the consumer-facing workflow
- API reference — when you need to wire this into your billing or HR system