claude-code - 💡(How to fix) Fix [FEATURE] Per-user authentication for organisation MCP connectors [1 comments, 2 participants]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Summary

Organisation-level MCP connectors on claude.ai currently use a single shared OAuth token for all
users in the org. This makes it impossible to build user-scoped MCP servers — where the API
returns only the data a given user is authorised to see.

The problem

We built an internal MCP server with user-scoped auth: each user authenticates with their own
credentials, and the API enforces data visibility based on their permissions. This is the correct security model for a multi-tenant internal tool.

When configured as an org connector on claude.ai, this falls apart completely:

• All users share one token — whoever re-authenticates last sets the token for everyone
• If a user without full access re-auths, they break the connector for the whole org
• There is no way to enforce that each user's requests are scoped to their own identity

Expected behaviour

When a user in an org invokes an MCP connector, claude.ai should authenticate as that user, not as a shared org identity. The OAuth flow should be triggered per-user, and tokens stored and used
per-user.

Why this matters

This is a hard blocker for any internal tool that has row-level or user-level data access control. The current model only works for connectors backed by a single service account (public APIs,
shared databases). It cannot support the far more common case of enterprise tools where "what you see depends on who you are."

Proposed Solution

• Allow org admins to mark a connector as "per-user auth required"
• On first use, each user goes through the OAuth flow individually
• Tokens are stored and refreshed per user, not per org

Alternative Solutions

No response

Priority

Critical - Blocking my work

Feature Category

MCP server integration

Use Case Example

1. We built an internal real estate deal management tool (ValueTrack) with an MCP server that exposes deal, company, and asset data to Claude.

2. The MCP server uses user-scoped authentication — each user logs in with their own credentials, and the API returns only the data they are authorised to see (row-level access control).

3. When configured as an org connector on claude.ai, all users in the org share a single OAuth token. Whoever authenticates last sets the token for everyone. If a user with limited access re-auths, they break the connector for the whole org.

4. This makes it impossible to use claude.ai as a front-end for any internal tool with per-user data access control. The feature would unblock this entire class of enterprise MCP integrations.

Additional Context

The current shared-token model works fine for connectors backed by a public API or a single service account (e.g. weather, search). It fundamentally cannot support the common enterprise pattern where "what you see depends on who you are."

Proposed behaviour: org admins can mark a connector as "per-user auth". Each user goes through the OAuth flow individually on first use. Tokens are stored and refreshed per user, never shared across the org.

This is consistent with how OAuth is designed to work and how every other enterprise SaaS handles delegated access.