Scopes tell you what a token is allowed to ask for. They do not tell you which of your customer's employees should have been given that token in the first place. That second question is the one an enterprise buyer asks, and it is usually the one a first MCP server has no answer to: "Our finance team can see payroll and our support team cannot. How does your server know the difference?"
The answer has to come from the customer's identity provider, because that is where the answer already lives. This is a guide to getting group and entitlement data out of an IdP and into an MCP server's authorization decisions, and to the parts that are harder than they look.
Three separate decisions
Enterprise access for an MCP server is three decisions, and conflating them is the usual source of trouble.
- Installation. May this MCP client connect to this server for this tenant at all? Decided once, by an administrator.
- Entitlement. May this user use this server, and which capabilities within it? Decided by the customer's identity governance, usually through group membership.
- Authorization. May this specific tool call, with these arguments, touch this record? Decided by your server at call time, from the token and your own data model.
OAuth scope only carries the second decision, and only as a ceiling. The third is yours no matter what the token says. The first is not an OAuth question at all; it is a provisioning question, and it is the one most servers skip.
Do not let the user install the connector
The default MCP flow is user-initiated: a person adds your server to their client, runs an authorization code flow, and consents. For a consumer product that is correct. For an enterprise customer it is a finding, because it means any employee can bind a corporate identity to a third-party agent host that the security team never approved.
What enterprise buyers expect instead:
- An administrator authorizes the connection for the tenant, choosing which client applications are permitted.
- Individual users still run their own authorization code flow, so tokens remain per-user, but only inside a tenant the administrator has enabled.
- The administrator can see which users have connected, and can end that for one user or for everyone.
Concretely, that is a tenant record in your server that says which client identifiers are allowed, plus a check in the authorization flow that refuses an otherwise valid user if their tenant has not been enabled. It is a small amount of code and it removes an entire category of review questions. It is also the honest place to enforce the customer's decision that MCP access is limited to a pilot group.
Getting entitlements: claims, lookup, or provisioning
Once a tenant is enabled, your server needs to know what a given user is entitled to. There are three mechanisms, and most deployments end up using two of them.
Claims in the access token. The IdP puts group or role claims into the token (RFC 9068 describes the JWT access token profile these usually follow). Simplest to consume, and the data arrives already signed. Two limits: group claims are frequently truncated by the IdP above some number of groups, which fails open in the worst way if you treat "no claim" as "no groups"; and the claim is only as fresh as the token's lifetime.
Lookup at authorization time. Your server queries the IdP or directory for the user's groups when it issues a session. Avoids truncation, costs a network call, and requires a credential of your own with directory read access — which is itself something the customer's reviewer will ask about, so keep it read-only and narrowly scoped.
Provisioning ahead of time. The customer pushes users and groups to you with SCIM (RFC 7644), and your server keeps its own copy. Best fidelity, best deprovisioning story, and by far the most work. Ask for it when the customer already runs SCIM for your main product; do not build it for a pilot.
Whichever you use, write down which one is authoritative. A server that reads a group claim when present and falls back to a lookup when absent has two authorization models, and reviewers find that out.
Map groups to capabilities, not to tools
The tempting mapping is direct: group mcp-invoices grants tool get_invoice. It does not survive contact with a real directory. Customer group names are theirs, they change, and one group typically corresponds to a job, not to a tool.
Use an intermediate layer the customer configures:
- Your server defines a small, stable set of capabilities —
invoices.read,invoices.write,admin.export— derived from the same permission table your tool design came from. - The tenant configuration maps the customer's group identifiers to those capabilities. The customer owns this mapping and can change it without a deploy from you.
- Tools declare which capability they require. The requested OAuth scopes for a session are the intersection of what the client asked for and what the user's capabilities allow.
The intersection matters. A client that asks for every scope should receive a token carrying only what that user is entitled to, not a denial and not a superset. And the capability check runs again in the handler at call time, against the record being touched. Scope narrows the ceiling; the entitlement check sets the floor; neither replaces row-level authorization in the data layer.
Staleness is the part that fails
Entitlement data is a cache, and every cache has a staleness window you must be able to state in a sentence. When someone moves from finance to support on Monday, when does their agent stop seeing payroll?
Decide and document three numbers: access token lifetime, entitlement refresh interval, and the maximum time between a change in the IdP and enforcement in your server. Keep access tokens short (minutes, not days) and re-evaluate entitlements on refresh rather than only at first login. If you have a shared-signals receiver or SCIM feed, say what it covers and what it does not. If entitlement changes only take effect at the next refresh, say that too — a reviewer will accept a documented fifteen-minute window far more readily than an undocumented one. Offboarding an entire account is a related but distinct path; we covered it in revocation and offboarding.
What a reviewer wants to see
For this area, four artifacts answer nearly every question:
- The capability catalog, with the tools each capability gates and whether it reads or writes.
- The tenant configuration screen or API where the customer maps their groups, plus who in their organization is allowed to change it.
- A worked example: one user, their groups, the resulting capabilities, the scopes in their token, and one call that was denied because of them.
- The staleness numbers above, with the mechanism that enforces each.
The worked example does the most work. It converts an architecture claim into something a reviewer can check, and it belongs in the security evidence pack alongside the threat model.
When you do not need this
If your product has no concept of roles — every user of a customer's tenant sees the same data — group mapping adds a configuration surface that nobody will use. Enforce tenant isolation and per-user data access, publish the capability catalog as a fixed list, and say plainly in the questionnaire that entitlement is inherited from the product's own access model. That is a defensible answer. Building a group mapping engine you cannot populate is not.
Where identity mapping does get hard is a gateway fronting several MCP servers for one enterprise, because the mapping has to hold across servers that were built by different teams with different permission models. That is the work in a governed MCP platform, and if you are approaching that shape, an audit of the servers you already have is the cheaper first step.