Skip to content
Back to skills

Oauth Scope Planner

ASecurity

Design the OAuth 2.1 scope set, pinning rules, and step-up policy for a remote MCP server. Use when you need help with oauth scope planner.

  • 9 stars
  • 0 votes
  • 0 copies
  • 4 views
  • Added September 8, 2026
developmentrustapi

Works with

  • cli
  • api
  • mcp

Security analysis

A100/100

Scanned September 8, 2026

npx -y skills add anubhavg-icpl/vibe --skill oauth-scope-planner --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Oauth Scope Planner?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Oauth Scope Planner
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/anubhavg-icpl-oauth-scope-planner/badge)](https://www.skillsdirectory.com/skills/anubhavg-icpl-oauth-scope-planner)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: oauth-scope-planner
description: Design the OAuth 2.1 scope set, pinning rules, and step-up policy for a remote MCP server. Use when you need help with oauth scope planner.
license: CC-BY-NC-SA-4.0
phase: 13
lesson: 16
metadata:
  version: 1.0.0
  tags: [oauth, pkce, resource-indicators, step-up, sep-835]
---

Given a remote MCP server with a tool list, design the authorization model.

Produce:

1. Scope hierarchy. Graduated scope set (e.g. `read` -> `write` -> `delete` -> `admin`). One scope per operation class; do not explode the scope set.
2. Scope-to-tool mapping. Each tool annotated with its required scope. Flag any tool that needs more than one scope.
3. Step-up policy. Which operations require step-up rather than an initial consent. Typical: destructive operations require step-up.
4. Resource indicator value. The canonical URL used in the `resource` parameter. Ensure the URL matches the `.well-known/oauth-protected-resource` resource field.
5. Protected-resource metadata. Draft `.well-known/oauth-protected-resource` JSON with `authorization_servers`, `scopes_supported`, and `resource`.

Hard rejects:
- Any tool that requires admin scope but is invoked without an explicit confirmation dialog. Needs step-up.
- Any scope that covers more than one operation class. Privilege creep.
- Any server that skips audience validation. Confused-deputy vulnerability.

Refusal rules:
- If the server is local (stdio), refuse OAuth and state that stdio inherits parent trust.
- If the server depends on a legacy OAuth 2.0 implicit flow, refuse and mandate migration to 2.1 + PKCE.
- If the user asks for passwordless "API key only" auth, refuse for remote servers; require OAuth 2.1 authorization code + PKCE with resource indicators for user-authorized access. Client credentials is only appropriate for machine-to-machine scenarios without user delegation.

Output: a one-page authorization plan with the scope hierarchy, scope-to-tool mapping, step-up policy, resource indicator, and the protected-resource metadata JSON. End with the step-up operation most likely to surprise users on first encounter.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.