MCP OAuth Security Testing: Tokens, Scopes and Delegation

An OAuth login completing successfully does not establish that an MCP server enforces the correct resource, user and tool permissions. MCP OAuth security testing should follow the token from authorization through the server to any downstream API, then verify what each component is actually allowed to do.

This method is for authorized staging environments with designated accounts and synthetic resources. It provides test cases and expected outcomes; it does not report a completed audit of a particular MCP implementation.

Identify the transport and authorization roles

First distinguish a remote HTTP MCP deployment from a local stdio server. They have different credential and execution boundaries. The MCP authorization specification describes the HTTP authorization flow and token validation requirements. Do not assume that a local process uses that flow merely because it exposes MCP tools.

For a remote deployment, record the MCP client, resource server, authorization server, registered client, resource identifier and downstream APIs. Note which identity owns each operation: a human, a service or a delegated agent. A downstream API credential and the credential presented to the MCP server may have different issuers, audiences and privileges.

Prepare valid controls before rejection cases

Create a minimal read-only account and an account permitted to use one controlled write operation. Use a synthetic resource and a write stub or disposable staging object. Establish that the intended read and approved write work first. Retain configuration and policy revisions so an unrelated outage does not look like an authorization fix.

Use test tokens issued by your own staging authorization infrastructure. Where a rejection case cannot be constructed through that infrastructure, use an isolated integration test or record the coverage gap. Never paste a live production token into a third-party decoder. Redact bearer tokens from screenshots and logs.

Test token audience and issuer validation

The MCP specification requires a server to validate that access tokens were issued specifically for it as the intended audience. A correctly signed token for another resource must not become a universal access pass. Likewise, discovering authorization-server metadata does not remove the need to bind the resulting trust configuration to the intended deployment.

Log the validation category, subject reference, resource identifier, policy revision and operation outcome. An HTTP rejection is useful, but verify the downstream side effect as well. A request that writes first and returns an error later has failed the security property.

Evaluate scope at the tool and object boundary

Document how OAuth scopes map to tool names, argument constraints and individual objects. A broad scope such as application access is not evidence that a subject should read every tenant’s objects. Test the same tool against an allowed and denied fixture while keeping the subject constant.

Also check discovery separately from execution. Hiding a tool from a list may reduce exposure, but the server must enforce permissions when a call arrives. An authorization test should exercise the documented invocation path for the known tool and inspect the result. Do not use undisclosed or guessed production interfaces.

Investigate token passthrough and confused deputy risks

The official MCP security best practices discuss token passthrough and the confused deputy problem. Audit credential routing: which service receives the client credential, which service validates it, and what credential authorizes the downstream call? A token forwarded unchanged to an unrelated service can undermine the resource boundary.

Do not label every delegated OAuth flow as passthrough. A documented flow using separately scoped credentials or an appropriate token exchange must be assessed against its own trust model. Record issuer, audience and privilege at each hop without retaining raw tokens.

For a deputy test, give the server a privileged downstream staging capability while the requesting account has only minimal rights. Ask for the forbidden synthetic operation through the normal application workflow. The server should bind the user’s permission to the operation before using its own privilege. A policy denial in the model’s answer is insufficient if the tool still executes.

Check redirect and authorization response binding

Inspect the registered redirect rules and the client’s authorization transaction binding, including the protection required by its OAuth flow. Test unexpected redirect values and authorization responses that do not belong to the active test transaction in an isolated client integration test. A rejected response must not establish a session for a different user or resource.

Keep evidence at the trust boundary: the selected authorization server, client identity, redirect validation decision and session outcome. Report the security property and exact observed response; do not infer a vulnerability from a redirect string appearing in a log. Localhost redirects and native clients have implementation-specific considerations, so use the protocol’s security guidance for the deployed client type.

Define revocation and approval semantics explicitly

Token expiry, refresh-token revocation, access-token revocation and application permission removal are different events. Determine which events the deployment supports and the promised propagation window. Some self-contained access tokens remain valid until expiry unless an additional mechanism enforces earlier revocation. Test the actual contract rather than assuming every revocation is instantaneous.

For an approved write, bind the approval to the subject, tool, target object and arguments. Change one of those fields in staging after approval and verify whether the operation requires a new decision. A valid OAuth session does not establish that a human approved every later action.

Deliver an MCP authorization audit record

Case: read-only subject attempts staging write
Client / server revision: record exact deployed builds
Subject and tenant: designated test identity
Token metadata: issuer, audience, expiry; no raw token
Policy and scope: record effective mapping
Expected decision: deny before the write stub executes
Observed decision: not yet tested
Downstream side effect: not yet inspected
Evidence: redacted request ID, decision log, stub event
Retest: repeat denied case and valid allowed control

Classify missing visibility as inconclusive. Distinguish authentication rejection, scope denial, object denial and approval denial so remediation reaches the correct component owner. For the broader service inventory, local-server and tool-permission work, use the maintained MCP security testing checklist.

Keep the authorization-boundary evidence with the remediation record. If you are evaluating AI-assisted penetration testing for the surrounding application and API attack surface, create a Penligent account and confirm the supported scope before starting. The assessment method here does not imply that every model, identity provider or agent runtime is automatically covered.

Review the workflow before an MCP test

The official Penligent 3.0 demonstration provides interface orientation. Keep the OAuth audience, scope, delegation and revocation cases above in your assessment brief; this video does not establish MCP conformance or authorization coverage.