SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsremote-oauth-mcp-pentest

remote-oauth-mcp-pentest

Agents & models

View repository

Updated 10-16 08:38

About this skill

Remote OAuth MCP Pentest

Authorized testing of remote MCP servers using browser/OAuth-style login. Read ../../SECURITY_RULES.md first — it overrides anything here.

Operating rules (non-negotiable)

  • Authorized targets only. Confirm scope + named authorizer before phase 1.
  • Read-only, non-destructive by default. Deny-by-default is the expected result of every negative test — a denial is a PASS, an allow is a FINDING.
  • Never exfiltrate real secrets; report type + location + first4/last4 only.
  • Server-side authorization is the control under test. Browser login proves identity, not tool authorization.
  • Show the plan before running live probes.

Deliverables (produce all of these)

  • Remote OAuth Flow Map — use ../../templates/remote-oauth-flow-map.md
  • MCP Endpoint Inventory
  • Protected Resource Metadata Review — protected-resource-metadata-checklist.md
  • Authorization Server Metadata Review — auth-server-metadata-checklist.md
  • Token Validation Matrix — token-validation-checklist.md
  • Scope-to-Tool Matrix — scope-tool-mapping-template.md
  • Per-Tool Authorization Matrix
  • Tenant Isolation Test Plan — tenant-isolation-checklist.md
  • API Token Fallback Review
  • Consent Boundary Review — consent-boundary-checklist.md
  • Confirmed Findings / Suspected Findings / Passed Checks
  • Prioritized Fix Plan
  • Regression Test Plan

Hand raw notes to the security-report-writer skill to assemble the report.

Phases

1. Scope and authorization

  • Record allowed hosts, tools, accounts, time window, named authorizer.
  • Identify environments: production vs staging. Prefer staging.
  • Confirm you have (or can create) test identities: normal user A, normal user B (different user), admin user, and users in two different tenants/orgs.
  • STOP if authorization is unclear.

2. Remote MCP endpoint inventory

  • Base MCP URL and transport (Streamable HTTP / SSE / other).
  • initialize, tools/list, tools/call, resources/*, prompts/* paths.
  • Any .well-known/* discovery endpoints.
  • Any sibling HTTP API (hand off to endpoint-pentest).
  • Record which endpoints answer without a token.

3. OAuth/OIDC discovery review

  • On an unauthenticated request, does the MCP server return 401 with WWW-Authenticate pointing at the resource metadata?
  • Follow ../../playbooks/oauth-discovery-review.md.

4. Protected Resource Metadata review

  • Use protected-resource-metadata-checklist.md.
  • Confirm resource identifier and correct authorization_servers.

5. Authorization Server Metadata review

  • Use auth-server-metadata-checklist.md.
  • Confirm issuer, endpoints, PKCE support, supported scopes, DCR endpoint.

6. Browser login flow review

Follow ../../playbooks/browser-login-flow-review.md. Determine:

  • what opens the browser; where the callback lands;
  • how the code/token returns to the MCP client; where tokens are stored;
  • whether tokens are encrypted at rest; token lifetime; refresh; revocation; logout behavior;
  • whether consent text matches the actual tools;
  • whether destructive tools are clearly described;
  • whether admin tools require separate role/consent;
  • whether browser login can be bypassed via API-token fallback;
  • whether tokens leak via URL fragments, logs, referer headers, browser history, or error messages.

7. PKCE and redirect URI review

Follow ../../playbooks/pkce-callback-review.md. Check:

  • PKCE required for public clients; state present and validated;
  • authorization code single-use; code replay rejected;
  • redirect URI exact-match / strict allowlist; wildcards rejected;
  • localhost and custom-scheme callback behavior understood/documented;
  • open-redirect risk; callback error leakage.

8. Dynamic client registration review

Follow ../../playbooks/dynamic-client-registration-review.md. Check whether DCR exists, whether arbitrary clients can self-register, whether public clients can get excessive privileges, whether client metadata (name/logo/URL) is sanitized (agent-context poisoning risk), redirect-URI validation at registration, scope restriction, rate limiting, and whether registration grants privileged access.

9. Token validation tests

Use token-validation-checklist.md. For each case the expected result is deny: missing header, malformed header, malformed token, expired token, unsigned / alg:none (where JWT), wrong issuer, wrong audience/resource, token for another MCP server, token for another user, no relevant scope, low-privilege scope, revoked token (if testable), replayed token/request (if testable). Generate invalid test tokens locally per ../../payloads/token-negative-tests.md.

10. Scope-to-tool authorization mapping

Fill scope-tool-mapping-template.md for every tool: name, description, read/write/destructive, required scope, required user permission, required tenant/org/project membership, required role, sensitive data returned, confirmation required, server-side authz check location, audit event emitted, regression test name.

11. Per-tool authorization testing

For every tool, test with: no token, malformed token, expired token, valid token with no relevant scope, read-only scope, token from another user, token from another tenant/org/project, token for another audience/resource, normal user, admin user, revoked token (if testable). Expected: deny-by-default; record each result in the Per-Tool Authorization Matrix.

12. User/tenant/org/project isolation testing

Use tenant-isolation-checklist.md and ../../payloads/tenant-isolation-tests.md. Safely vary user_id, tenant_id, org_id, project_id, workspace_id, account_id, and resource IDs in tool args; try sequential enumeration, IDs leaked from prior tool results, cross-workspace reads/writes, and mixing resources from different tenants in one request. One cross-boundary record is sufficient proof — do not bulk-pull.

13. API token fallback testing

Follow ../../playbooks/api-token-fallback-review.md. If API tokens exist: do they carry the same server-side authz as OAuth tokens? Can they bypass consent, scope, or tenant checks? Are they scoped, revocable, rate-limited, audited?

14. Replay/session behavior

  • Can a captured request be replayed after logout/revocation?
  • Are authorization codes and nonces single-use?
  • Does session/token rotation happen on privilege change?

15. Consent and destructive action boundary

Use consent-boundary-checklist.md. Identify tools that mutate/delete data, send messages/emails/tickets, trigger deploys/CI/jobs, or modify billing/permissions/users/tokens/secrets. Check for explicit user intent, server-side confirmation gates, honest side-effect disclosure, and whether the agent can be indirectly prompted into a destructive tool.

16. Audit logging review

Confirm logs capture: user identity, client identity, tenant/org/project, tool name, parameter fingerprint (not full sensitive values), authorization decision, outcome, request/correlation ID, timestamp, denial reason, error class. Logs must not store secrets or full sensitive payloads.

17. Findings and remediation

Classify Confirmed vs Suspected. For each finding: reproduction, impact, root cause, fix, regression test (../../templates/finding.md). Build a prioritized fix plan (../../templates/remediation-plan.md).

18. Regression tests

For every confirmed finding and every deny-by-default expectation, define an automated regression test (../../templates/regression-tests.md) so fixes stay fixed.

Reference checklists in this skill

  • oauth-flow-checklist.md
  • protected-resource-metadata-checklist.md
  • auth-server-metadata-checklist.md
  • token-validation-checklist.md
  • client-registration-checklist.md
  • consent-boundary-checklist.md
  • tenant-isolation-checklist.md
  • scope-tool-mapping-template.md
  • report-template.md