OAuth2 Provider Skill: What It Does and How to Install It
Helps you design the OAuth2 authorization server your platform offers third-party apps.
- Installs
- 9.6K
- on skills.sh
- Stars
- 9
- on GitHub
- Files
- 5
- besides SKILL.md
- Updated
- Nov 2026
- last repo commit
oauth2-provider-design makes Claude act as an OAuth provider designer. It builds in four stages: the OAuth 2.1 protocol core, scope taxonomy and consent screen, client registration and app verification, then advanced hardening only when justified.
It loads when you mention OAuth, "Sign in with X", access and refresh tokens, scopes, consent screens, PKCE or third-party apps acting on a customer's behalf. It covers the issuer side only, not integrating against someone else's OAuth. It asks six clarifying questions and bundles four reference files and no scripts.
Good for
- Platform engineers adding "Sign in with" or an app directory
- Teams with one all-access scope who need a scope taxonomy
- Product teams fixing a consent screen that admins reject
Install oauth2-provider-design
Claude Code
- 1
Copy this prompt.
Install the oauth2-provider-design skill in Claude Code. Run this command: /plugin marketplace add samber/developer-platform-skills /plugin install developer-platform-skills@developer-platform-skills Then check that it loaded and tell me how to use it.
- 2
Paste it into Claude Code. It shows the change and asks before running it.
The README installs every skill in the repo (61 skills/*/SKILL.md in the git tree), because skills here reference each other. oauth2-provider-design is one of them. Pick one route, not both.
From the project README. Source.
What's in the skill
When it loads
Design the OAuth2 authorization-server surface a B2B SaaS offers third-party apps - the OAuth 2.1 protocol baseline (PKCE for every client, no implicit or password grants, exact redirect matching), token TTL and refresh-rotation policy, scope taxonomy and granularity, consent-screen design with partial and incremental grants, client registration posture, and the tiered app-verification program. Use whenever the user mentions OAuth, "Sign in with X", access and refresh tokens, scopes, consent screens, PKCE, or third-party apps acting on a customer's behalf - even if they never say "OAuth provider". Issuer side only, not integrating against someone else's OAuth. Do NOT use for API-key design - use samber/developer-platform-skills@api-auth-key-management instead.
Sections in SKILL.md
- Clarifying questions
- Who consents: end user, org admin, or both
- Workflow
- 1. Protocol core
- 2. Scope taxonomy and consent screen
- 3. Registration and verification program
- 4. Advanced hardening - when justified
- Failure modes
- Measurement
- Invocation examples
- References
Key facts
- Author
- Samuel Berthe
- Version in SKILL.md
- 1.0.4
- Installs on skills.sh
- 9,644 (Nov 2, 2026)
- GitHub stars (repo)
- 9 (Nov 2, 2026)
- Last commit (repo)
- Nov 1, 2026
What it includes
Asks six questions, including who consents: end user, org admin or both.
Try: “Define the scope taxonomy for our public API's OAuth apps - today we have one `full_access` scope.”
Clarifying questionsSets an OAuth 2.1 baseline: PKCE for every client, no implicit or password grants.
1. Protocol coreDesigns scope granularity and consent with partial and incremental grants.
2. Scope taxonomy and consent screenSets client registration posture and a tiered app-verification program.
3. Registration and verificationAdds further hardening only when justified.
4. Advanced hardening
From the official docs
Permissions
Low risk
This skill writes design advice and bundles no scripts, so the main thing to watch is where your agent saves notes.
What it can do
- Read your data
- Create and change things
- Delete things
- Read-only mode
Watch out for
It may save notes to developer-platform-context.md
SKILL.md says that when your agent keeps memory in a file, it should consider using this file name. Our advice: keep it out of commits if it holds company plans. github.com
Technical details
| Scopes |
|
|---|
Questions
How do I install oauth2-provider-design?
Use the install box at the top of this page. The README says to install every skill in samber/developer-platform-skills, not one, because the skills hand work to each other. Pick one route per agent.
Does oauth2-provider-design work in Claude, Codex and Cursor?
The README documents install routes for Claude.ai (plugin marketplace), Claude Code, Codex, Cursor, Gemini CLI and the skills.sh CLI. The install box lists each one.
What does it ask me before it designs anything?
SKILL.md lists six questions to ask first, and the answers change the later steps. Have your current setup and constraints ready.
Does it run scripts or need an API key?
It bundles no scripts. The folder holds SKILL.md, reference Markdown files and an evals file, and the skill works by asking you questions and writing advice.
Is oauth2-provider-design safe to install?
It bundles no scripts, so installing it adds instructions and reference files rather than programs. SKILL.md also suggests that, if your agent keeps notes in a file, it uses developer-platform-context.md. Our advice: keep that file out of public commits if it holds company plans, and check any figures the skill cites against their sources before quoting them to customers.
How is it different from api-auth-key-management?
This skill designs the OAuth authorization server for third-party apps. SKILL.md says not to use it for API-key design and points to api-auth-key-management for that.
Information
updated Nov 2, 2026
- Repository
- samber/developer-platform-skills
- Folder
skills/oauth2-provider-design
Sources
Docs, issue trackers and discussions this page is built from.
Show all 2Hide
- samber/developer-platform-skills README · github.com
- oauth2-provider-design SKILL.md · github.com