Testing MCP OAuth Audience Binding and Least-Privilege Scopes

MCP OAuth security testing must prove where authority stops. A token that is cryptographically valid but accepted by the wrong resource is a security failure; a token with broad scopes that happens to complete the test is also a failure. Build the suite around negative authorization boundaries, not a single successful login.

The MCP authorization specification defines authorization for HTTP-based transports, assigns the MCP server the OAuth resource-server role, requires resource indicators in authorization and token requests, and requires the server to validate that a presented token was issued for it. Stdio has a different credential boundary and should not be forced through this HTTP OAuth test plan.

Draw the authorization trust map

Name every principal and endpoint before generating fixtures. The user or resource owner grants authority; the MCP client initiates OAuth; the authorization server authenticates, obtains consent when applicable, and issues the access token; the MCP server validates and enforces that token as a resource server. A database, SaaS API, or other service behind the MCP server is a separate downstream resource.

Record the canonical URI for each MCP endpoint, its accepted authorization servers, its scope-to-operation policy, and its downstream credential strategy. Do not collapse issuer and audience into one assertion. The issuer says who created the token; the audience says which resource may consume it. A legitimate issuer can issue tokens for several resources.

Test discovery as input validation. A forged resource_metadata location, an untrusted authorization-server URL, or unsafe redirect must not become a server-side request or browser redirect merely because it appeared in a challenge. Include tenant boundaries, endpoint paths, ports, and trailing-slash normalization in the URI inventory. Normalize only according to the documented contract; do not make two security resources equivalent for convenience.

Prove the resource indicator round trip

The client must include resource in both the authorization request and token request, using the intended MCP server's canonical URI. Capture those requests at the authorization-server boundary and assert the value, including encoding and exact path significance. Then inspect the validated token representation or introspection result at the resource server and prove it identifies that resource as an intended audience.

Use at least two real test resources controlled by the team. Obtain token A for MCP A, token B for MCP B, and attempt the full cross-product. A accepts A; B accepts B; A rejects B; B rejects A. Add a token issued by the same authorization server for an unrelated API. This is stronger than changing an unsigned fixture because it exercises issuance and enforcement together.

A client must not send a bearer token to an endpoint other than the resource for which it was issued. Network capture can verify the absence of token forwarding. Redact the credential value at capture time and compare a one-way test-only fingerprint if correlation is necessary.

Reject valid tokens with the wrong audience

Build negative tokens that vary one property at a time: wrong audience, absent audience according to your token profile, untrusted issuer, expired lifetime, not-yet-valid lifetime when represented, invalid signature, revoked or inactive status, malformed token, and valid token with insufficient scope. The wrong-audience case must fail before tool logic executes.

Do not test production validation by merely base64-decoding a JWT. Use the same trusted verification or introspection path as the server. This illustrative TypeScript boundary keeps token format behind an adapter:

type VerifiedAccess = {
  active: boolean
  audiences: string[]
  scopes: Set<string>
  subject: string
}

async function authorizeTool(
  bearer: string,
  expectedResource: string,
  requiredScope: string,
): Promise<'allow' | 'invalid_token' | 'insufficient_scope'> {
  const access = await trustedTokenVerifier.verify(bearer)
  if (!access.active || !access.audiences.includes(expectedResource)) {
    return 'invalid_token'
  }
  if (!access.scopes.has(requiredScope)) return 'insufficient_scope'
  return 'allow'
}

The adapter is responsible for integrity, issuer, time, revocation, and token-profile rules. The application layer receives verified claims, compares the configured resource, and checks the exact operation. Tests should assert that denial causes no downstream call, cache write, queue publication, or partial side effect.

Measure least privilege by operation

Create a permission matrix from operations, not tool names alone. A tool called files might list metadata, read contents, create a file, or delete one. Map each behavior to its minimum accepted scope set and explicitly list forbidden combinations. Scopes are opaque strings unless your authorization design defines hierarchy; never assume that files implies files:read or that a prefix grants descendants.

For every operation, run four probes: exact minimum scope, each required scope removed in turn, unrelated scope, and broader approved role if such a role exists. Verify both response and effect. A denied write with a 403 that still created a record is not a partial pass. Also prove that read-only authority cannot discover sensitive tool or resource details your policy considers unauthorized.

Keep administrative and destructive scopes out of ordinary sign-in fixtures. Separate test users by role, and obtain tokens through supported grants rather than mutating claims. This catches authorization-server mapping errors that synthetic tokens conceal.

Exercise challenges and step-up consent

The specification distinguishes missing or invalid credentials from insufficient permission. Test a request without a token and an expired token for 401 behavior. Test a valid, audience-bound token missing the required scope for 403 behavior and inspect WWW-Authenticate for error="insufficient_scope", the applicable scope guidance, and resource metadata when your server emits the recommended challenge.

The client should parse a challenge, request a new token through the authorization flow, and retry within a strict loop limit. It must not silently add privilege, reuse consent for a different client, or keep retrying a permanent denial. Cancelled consent must leave the original token and operation state unchanged. A user who denies a write scope should still retain previously granted read behavior if that matches the authorization-server policy.

Label each retry with the resource, operation, old granted scopes, challenged scopes, authorization transaction, and terminal result. Never put access or refresh tokens in those fields.

Keep downstream authorization separate

The MCP security best-practices guide explicitly identifies token passthrough as an anti-pattern. An MCP token is presented to the MCP server. It is not a convenient credential for a storage provider, calendar API, or internal microservice.

Test the MCP server with a downstream spy that rejects the client's token fingerprint and accepts only the server's configured downstream credential or token exchange result. Assert that downstream logs identify the MCP service identity and, where policy permits delegation, carry an explicit constrained subject mapping rather than an unvalidated upstream bearer. Rotate or revoke each credential independently and verify that failure remains at the correct boundary.

Include a confused-deputy scenario for proxy servers: one client must not inherit another client's approval, redirect registration, session, or third-party consent. Bind authorization transaction state to the client and user, verify redirects exactly, and make approval records queryable for incident review.

Model failures beyond status codes

Use a failure model with security impact and observability expectations:

Also inject verifier timeout, stale signing-key cache, introspection error, concurrent step-up requests, replayed authorization response, and clock skew at the documented tolerance edges. Do not convert verifier uncertainty into permission. Availability fallback must not weaken audience or scope checks.

Automate a denial-first matrix

Represent cases as data so every tool inherits the same boundary tests. The values below are fixtures, not universal MCP scope names:

{
  "fixtureLabel": "illustrative authorization matrix",
  "resource": "https://mcp.example.test/files",
  "cases": [
    {"operation": "file.read", "audience": "files", "scopes": ["files:read"], "expect": "allow"},
    {"operation": "file.write", "audience": "files", "scopes": ["files:read"], "expect": "insufficient_scope"},
    {"operation": "file.read", "audience": "calendar", "scopes": ["files:read"], "expect": "invalid_token"},
    {"operation": "file.delete", "audience": "files", "scopes": ["files:write"], "expect": "insufficient_scope"}
  ]
}

Run the matrix at the protocol boundary and against tool side effects. Preserve authorization server, policy revision, MCP server build, canonical resource, fixture identity, and correlation ID. Regenerate credentials per test run and destroy them afterward; recorded bearer strings are not test artifacts.

Use a release checklist with hard stops

• Confirm every HTTP MCP resource has an explicit canonical URI and trusted authorization-server set.
• Capture resource in authorization and token requests and test cross-resource rejection.
• Verify integrity, issuer, lifetime, active status, audience, and exact required scopes through the production validation path.
• Exercise 401, 403, challenge parsing, denied consent, bounded step-up, and token expiry.
• Prove denied operations create no direct, queued, cached, or downstream side effect.
• Detect token passthrough and test per-client consent isolation for proxy designs.
• Redact credentials from traces while retaining enough decision metadata to investigate a denial.

Block release when any wrong-audience token is accepted, any denied operation mutates state, the client leaks a token to another resource, or step-up can expand authority without the expected user decision. Scope wording can evolve; those boundaries cannot.