Skip to main content

Authentication Models

MintMCP separates how users authenticate to Virtual MCP servers (VMCPs) from how VMCPs authenticate to downstream MCP connectors. This separation lets administrators choose the right security posture per tool without forcing end users to think about secrets.

Connector authentication models​

There are two main authentication models, per-user authentication and shared service account authentication.

Per-user authentication is used for tools that require a user to be authenticated to tool APIs, e.g., you want to allow users to fetch Slack messages as themselves.

Shared service account authentication is used for tools where the underlying API needs authentication to access protected data, but many users can share the same service account. A common example is a read-only role for a database that gives sales team members access to tables for the sales role.

We'll dive deeper into each model below.

Per-user credentials​

Per-user mode lets MintMCP forward an individual's identity all the way to the underlying service. Virtual MCPs broker OAuth grants, API tokens, or other user-scoped secrets on behalf of each member and store them securely, refreshing them automatically as needed.

When to use it:

  • Personal productivity data (email, calendar, drive)
  • Systems where permissions differ per user or actions and access must be attributed to an individual
  • Compliance regimes that require end-to-end user traceability

Example: A Gmail MCP connector prompts each employee to authorize their account during first use. MintMCP stores the resulting OAuth refresh token, rotates it automatically, and injects it only when that user invokes a Gmail tool.

Shared service accounts​

Shared-credential mode keeps downstream secrets entirely within MintMCP. Administrators upload service-account tokens, API keys, or database passwords once, and MintMCP applies its policy layer to decide which members can trigger those tools without ever exposing the secret to the user.

When to use it:

  • Data sets meant for broad departmental reuse (knowledge bases, shared analytics)
  • Legacy systems without per-user OAuth support
  • Read-mostly workloads where a service account is easier to audit than thousands of user grants

Example: A Snowflake MCP connector uses a warehouse-specific service account. Users connect through the Virtual MCP, while MintMCP enforces which warehouses, schemas, or saved queries each role can touch.

Mixing strategies​

Organizations can mix both approaches within a single Virtual MCP. You might expose Gmail and Slack with per-user credentials while granting read-only analytics tools through shared accounts. MintMCP keeps the user-facing experience consistent even when connectors apply different models.

Virtual MCP authentication options for clients​

MintMCP OAuth​

Every Virtual MCP exposes an OAuth 2.0-compatible endpoint. AI clients use this flow to obtain access tokens that represent the authenticated human plus the selected Virtual MCP.

Enterprise SSO​

For customers on an enterprise plan, MintMCP can delegate the AI client -> MintMCP part of authentication to your identity provider. We support SSO integrations across Okta, Google Workspace, Azure AD, and other SAML or OIDC providers. See the SSO configuration guide for detailed steps to connect Okta and other providers. Contact the MintMCP team to get started on an enterprise plan.

Access governance and tooling configuration​

Administrators layer role-based or attribute-based policies on top of OAuth. These policies decide which Virtual MCPs a user can see, which connectors each Virtual MCP exposes, and what parameters a given tool can accept. Tool manifests can be scoped to individual business units, and secrets never leave MintMCP.

Compliance considerations​

Every call through a Virtual MCP produces audit logs that include the human identity, Virtual MCP, connector, tool, and payload metadata. Logs feed into MintMCP dashboards or can be exported for SIEM integration. Use these records to satisfy SOX, SOC 2, HIPAA, or internal risk reporting.