# Remote OAUTH MCP Pentest

> Authorized security assessment of REMOTE MCP servers that use browser-based OAuth/OIDC login (Jira/Rovo-style). Drives an 18-phase review of the OAuth flow, discovery metadata, token validation, scope-to-tool mapping, per-tool and per-tenant authorization, API-token fallback, consent boundaries, and audit logging. Safe-by-default, read-only, deny-by-default. Use when auditing a remote MCP server reached over HTTP with an OAuth login step.

- Skill: `rwcod/remote-oauth-mcp-pentest` (Agent Skill, multi-file: 10 files)
- Install (CLI): `npx skillmds@latest add rwcod/remote-oauth-mcp-pentest`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rwcod/remote-oauth-mcp-pentest/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: rwcod (https://skillmd.com/u/rwcod)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/rwcod/remote-oauth-mcp-pentest

---


# Remote OAuth MCP Pentest

Authorized testing of **remote MCP servers using browser/OAuth-style login**.
Read [../../SECURITY_RULES.md](../../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`