For a protected remote MCP integration, design connection authorization and business-record access as separate decisions. A valid token lets the server evaluate a request from an authorized client; your application must still determine which organization, records, and actions that request may reach. A successful connection is only the beginning of that decision.

This guide uses a fictional invoice service to show what a SaaS team should settle before implementation. The examples are design proposals, not a tested integration or customer result. The focus is an HTTP-based MCP server that exposes private business information.

Draw the participants before choosing a login screen

In the MCP authorization model, the MCP client requests access, the authorization server issues tokens, and the protected MCP server receives requests as a resource server. The November 25, 2025 specification covers HTTP transports; its authorization flow is not the model prescribed for local stdio connections. See the MCP authorization specification.

For the invoice example, write down four concrete components:

Some components may share a deployment. Keep their responsibilities explicit even when they do. Assign an owner for the client connection, token validation, and application permission policy so failures do not become a chain of assumptions between teams.

Make the token's destination explicit

OAuth scopes describe the access being requested, while a resource indicator identifies where the client intends to use that access. RFC 8707 explains how the authorization server can use the requested resource to restrict a token to its intended audience. A scope name alone does not establish that destination. See Resource Indicators for OAuth 2.0.

For our fictional service, a planning note might read:

Protected resource: https://mcp.example.com/mcp
Requested capability: invoices:read
Application context: an organization the user may access
First tool: get_invoice_summary

This is an architecture note, not a complete OAuth request or a token example. The scope name is invented for this service; MCP does not define a universal invoices:read permission.

Under the cited MCP specification, clients include the resource parameter in authorization and token requests, and servers validate that incoming tokens were issued for them. A token issued for a different API must not be accepted merely because it is otherwise valid. See the specification's audience validation requirements.

Decide the canonical resource identifier with the authorization team before onboarding clients. Write it into the integration contract and include the wrong-resource case in your tests. Avoid treating similar-looking hostnames or endpoint paths as interchangeable without an explicit policy.

Map the approved connection to a business account

Suppose Maya connects the assistant to the invoice service. She belongs to Company A, where she may read invoices, and Company B, where she may view projects but not billing information.

Her approval of an invoices:read request should not silently grant billing access in Company B. In this proposed design, effective access requires all of the following:

  1. The incoming token passes the server's validation.
  2. The granted capability covers the requested tool action.
  3. The authenticated subject maps to an active application user.
  4. The selected organization is available to that user for the requested action.
  5. The invoice and returned fields satisfy the application's permission policy.

These are recommended application rules for the example. They are not a claim that an OAuth library automatically implements tenant membership or billing roles.

Record how the subject-to-user mapping is established. An email address typed into a tool argument cannot substitute for validated identity. If the user can select an organization, check that selection against trusted application state before using it.

The previous guide on read-only MCP tools and permissions covers record and field checks in more detail. Here, the additional design question is how the authorized connection reaches those checks with a reliable identity and account context.

Keep the downstream API boundary separate

Your MCP server may need to call a second protected API to obtain invoice data. That creates another authorization relationship. MCP security guidance explicitly forbids token passthrough: accepting a token from the client and forwarding it unchanged to a downstream API bypasses the intended token boundary. See the MCP security best practices.

For the example service, document the downstream credential separately from the incoming MCP token. Establish who issues it, which API accepts it, and how the resulting API request remains limited to Maya's allowed action and organization. The right mechanism depends on your existing identity system and API architecture.

A backend credential with broad access makes that last point especially important. The application's ability to fetch an invoice does not demonstrate that Maya may receive it. Have the implementation review trace one request all the way from validated identity to the returned invoice summary.

Do not put access tokens in tool arguments, screenshots, example prompts, or troubleshooting notes. A useful diagnostic record can identify the failing stage without reproducing the credential.

Distinguish connection failures from permission decisions

The MCP authorization specification calls for HTTP 401 for invalid or expired tokens and HTTP 403 for insufficient permissions or invalid scopes. It also defines protected-resource metadata for authorization-server discovery. These transport concerns should be handled by the client and server integration, rather than hidden inside a successful tool response. See MCP authorization error handling.

For product design, create separate user journeys for three outcomes:

That separation can prevent an unhelpful loop in which a user repeatedly reconnects to solve a role restriction. Avoid disclosing the owner or contents of an inaccessible invoice while explaining the failure.

Test the boundary, not just the connect button

A successful login demonstration leaves several important questions unanswered. For this example, prepare synthetic users, organizations, and invoices, then test these cases through the actual client-to-server path:

For each case, record the expected authorization decision, whether the downstream API was called, and which fields were returned. Use synthetic data and redact credentials. These checks are a starting set for the proposed design, not a substitute for a full security review.

Turn the decisions into an implementation brief

Before building, capture the resource identifier, supported client onboarding approach, initial scopes, user mapping, organization selection, record policy, downstream credential model, and failure journeys. The brief should let another engineer follow a single invoice request without guessing who authorizes each step.

Then keep the first tool set small enough to verify end to end. Our guide to mapping OpenAPI into MCP tools explains where generation can help and where design work remains.

If you are still establishing that initial scope, the Agent Readiness Audit can help frame proposed tools from your API documentation. Verifying OAuth behaviour and business permissions requires implementation evidence beyond documentation alone.