Skip to main content

Give a team access in one click

You have an MCP server. Five engineers should be able to use it. You could bind each engineer to the role individually — but next month a new engineer joins, two leave, and someone's role changes. Maintaining five bindings (or fifty) by hand falls apart fast.

Groups exist so you only manage that list in one place.

The model​

In AuthSec a role ("Deploy Operator", "PR Writer", "Auditor") collects the access. A binding attaches that role to someone. Bindings can attach to three kinds of someone:

  • A user — Alice specifically holds this role.
  • A group — everyone in engineering holds this role. Add/remove members of the group and the access follows automatically.
  • A service account — a non-human identity (a CI job, an AI agent) holds the role.

You can mix and match. A role can have one binding per group, plus a couple of direct user bindings for one-off exceptions.

When a group binding is the right call​

Use a group when:

  • Two or more people will hold the role, and the set will change.
  • A directory sync (SCIM from your IdP, OIDC group claims) populates the membership.
  • You want one place to take access away during an incident: drop someone from the group, every binding they got via that group is gone.

When a direct user binding is the right call​

Use a direct binding when:

  • The grant is genuinely individual — a temporary elevation, a one-off audit role.
  • The binding has user-specific conditions (locked to that person's office IP, expires in 4 hours).
  • You only need it for one person and don't expect that to change.

A worked example​

You're running a GitHub MCP server and a deploy MCP server.

Group  engineering   →  PR Writer role on github-mcp
Group  on-call       →  Deploy Operator role on deploy-mcp  (requires MFA)
Direct alice         →  Auditor role tenant-wide  (expires next week)

Alice is in engineering and on-call. Her effective access:

  • Can write PRs via the GitHub MCP (from engineering).
  • Can deploy via the deploy MCP, but the AI client will be asked to step up to MFA first (from on-call).
  • Can read audit logs (direct binding), until next week.

You can see this exact view in the admin UI under Effective Access — paste Alice's user ID and you get the full list, with each binding tagged direct/group/service-account so you know where it came from.

Suspend > revoke​

Need to cut someone off now? Don't rewrite bindings. Open End Users or Team, set their status to suspended. Every token they hold stops working on the next introspection. Reactivate to restore.

This is the cheapest "kick everyone out" lever in the system. Use it during incidents, on offboarding, or while you investigate.

What scope they actually get​

Even with all the right bindings, the token a user receives is the intersection of three things:

  1. What they're entitled to — the union of all their bindings (direct + group + service-account).
  2. What the Application supports — its declared scopes_supported.
  3. What the AI client asked for — the scope parameter in the OAuth request.

This means an AI client can never get more than the user holds, even if the AI client asks for the moon. And the user never sees a scope on a token that the Application doesn't actually understand.

Where this lives​

  • Admin UI → Authz → Groups (create, manage members, bind to roles).
  • Admin UI → Authz → Effective Access (paste a user ID, see everything affecting them).
  • Admin UI → Settings → Team (operator members) and End Users (consumers).

API reference (for the directory-sync use case)​

If you want to provision groups and memberships programmatically (e.g. from a SCIM pipeline), see:

  • POST /uflow/v2/groups/:group_id/role-bindings — attach a role to a group.
  • GET /uflow/v2/users/:user_id/effective-access — what does this user effectively have, today?

Full schema in the API reference.