Oauth Connector Blueprint

The number-one reason agent connectors die in production is authentication done wrong: tokens in plaintext files, no refresh logic (so the integration "randomly" breaks every hour), PKCE skipped, scopes over-requested. This skill gives you a complete, provider-aware OAuth 2.0 blueprint for agent connectors: the authorization-code flow with PKCE, automatic token refresh with rotation, secure token storage, scope-minimization guidance, and the quirks of major providers (Google, GitHub, Slack, Microsoft, Notion, and others) — as copy-paste-ready code plus a security checklist.

To produce a correct, secure OAuth 2.0 implementation for an agent connector: the full authorization flow, token lifecycle management (acquire → store → refresh → revoke), per-provider configuration, and a threat-model checklist. The output is code plus the reasoning, so the builder understands why each piece exists and does not cargo-cult it into insecurity.

• When your agent connector needs to act as a user against a third-party API (read their Gmail, post to their Slack, access their Notion).

• When adding "Sign in with X" to an agent-facing service or MCP server that serves multiple users.

• When an existing connector's auth "randomly stops working" — usually expired tokens with no refresh; this skill diagnoses and fixes the lifecycle.

• When reviewing someone else's OAuth implementation for security holes.

• For machine-to-machine auth (service accounts, API keys) — that is simpler and covered in mcp-server-scaffolder's auth layer; do not use OAuth where an API key suffices.

• When the provider does not support OAuth 2.0 (some legacy APIs) — the skill will tell you and suggest the provider's actual mechanism.

• For implementing an OAuth provider (authorization server) — this skill is the client side only.

• When you need the legal/ToS review of scopes and data handling — the skill covers the engineering; your lawyer covers the rest.