Remote OAUTH MCP Pentest

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