One connector, several trust models
The integrations in cursor/plugins do not share one generic notion of login. They use client registration, user OAuth, personal access tokens, service-account keys, provider scopes, and client-version gates for different jobs. This chapter compares those trust models so a reader can tell who is identified, who is authorized, and where least privilege must be applied.
The practical mistake to avoid is treating a client ID, a successful sign-in, and an allowed operation as the same event. A plugin may need an administrator to register an integration before a user can authenticate. A user may authenticate successfully but have access to only some records. A client may be able to host a plugin while the provider or marketplace hides it from another client. The connection is a chain of identities, not a single credential.
A client ID identifies an integration, not a person
Gong makes the first distinction clear. Its plugin manifest requires a client ID and client secret from an administrator-created MCP integration. The README then requires each member to complete their own Gong OAuth login. The static values identify the registered application. The user login supplies the account context under which tool calls run.
Salesforce has a similar split with different setup objects. The plugin requires a server URL and consumer key. The README says the integration uses an External Client App, specific OAuth scopes, public-client PKCE, and an individual Salesforce login. The consumer key identifies the client application. It does not decide which Salesforce records the signed-in person can access.
This distinction matters for ownership and revocation. An administrator can change or disable the integration registration without changing a person’s identity. A user can revoke their own authorization without changing the client’s registration. A team marketplace can configure a shared client value while still requiring each member to authenticate separately. If those layers are collapsed into “the plugin has access,” the reader cannot tell whose authority is being exercised or which party can withdraw it.
The plugin repository is mostly a wiring layer for this relationship. It declares the variables and passes them to the MCP server. It documents the setup and callback flow. The provider still decides how the application registration, user account, and operation scope interact.
OAuth, PATs, and service-account keys place authority differently
OAuth is a delegation flow. Google Drive uses OAuth 2.0 and prompts the user to sign in. Gong and Salesforce combine an application registration with per-user authorization. The credential is not merely a string that the user pastes into the plugin. The host and provider coordinate a flow that binds a user account to an integration.
A personal access token is more direct. GitHub’s plugin sends a bearer token header to the remote MCP server. The README recommends fine-grained tokens scoped to the repositories and operations the agent needs, rather than a broad classic token when narrower access is enough.