Authenticating to the MCP server

OAuth surface#

Least privilege#

Protected-resource metadata advertises every production business scope so clients can discover read and write step-up. Individual tools still request only the minimum scope they need. Business-write is a stronger permission and can read the same bound business. Offline access is requested separately when needed. Production authorization does not advertise or grant owner diagnostic scope.

The consent page names the registered MCP client, signed-in Connect identity and selected business. Private tools then re-check their required scope and live business authority.

Public calls#

Documentation tools remain callable without OAuth because they read the public generated corpus. A bearer token does not widen a public documentation tool.

Registration and redirect rules#

Connect supports dynamic client registration for public MCP clients. A web callback must use HTTPS. A native or command-line client may use plain HTTP only on a loopback host such as 127.0.0.1, ::1 or localhost; a remote HTTP callback is refused. Redirect URIs cannot contain embedded user information or a fragment. The exact registered URI is checked again during authorization and token exchange, so accepting more than one marketplace vendor does not turn the authorization endpoint into an open redirect.

Public clients receive no client secret from registration. The authorization code is protected with PKCE S256 instead. A bad verifier consumes and refuses the code, which prevents a failed exchange from becoming a reusable credential attempt. The resource parameter is also checked against the exact MCP resource, so a code intended for Connect's MCP endpoint is not a general token for another audience.

Token lifetime, rotation and live authority#

Access and refresh values are opaque credentials; the raw access token is not stored as a database primary key. Refresh tokens rotate when used, and revocation is a first-class endpoint rather than an instruction to wait for expiry. More importantly, token verification rechecks the user's workspace membership and role instead of assuming that authority remains true until the token expires. Removing a membership therefore invalidates the delegated path on a later request.

Business write is not a scope every signed-in member can consent to. The OAuth layer permits that scope only for live Owner or workspace-admin authority. The tool layer then checks again before a write. This repeated check is deliberate: scope answers what the client was granted, while live role answers whether the person still holds the organizational authority that made the grant valid.

Questions#

Related#

• The Connect MCP server
• Workspace MCP tools
• Integration keys
• OAuth for agents