AgentSkillsCN

oauth-reviewer

依据RFC 9700（OAuth 2.0安全最佳实践）审查OAuth 2.0的实现。在审查OAuth客户端或服务器代码、审计授权流程、检查令牌处理、评估PKCE的使用，或评估OAuth的安全态势时使用此功能。可通过“审查OAuth”“审计授权流程”“检查OAuth安全”或针对OAuth相关安全问题进行触发。

SKILL.md
--- frontmatter
name: oauth-reviewer
description: Review OAuth 2.0 implementations against RFC 9700 (OAuth 2.0 Security Best Current Practice). Use when reviewing OAuth client or server code, auditing authorization flows, checking token handling, evaluating PKCE usage, or assessing OAuth security posture. Triggers on "review OAuth", "audit auth flow", "check OAuth security", or OAuth-related security concerns.

OAuth 2.0 Security Review (RFC 9700)

Review OAuth implementations against RFC 9700 — OAuth 2.0 Security Best Current Practice.

Workflow

1. Determine Scope

Ask the user:

  • •Role: Client, authorization server, resource server, or combination?
  • •Client type: Public (SPA, native app, CLI) or confidential (server-side)?
  • •Grant types used: Authorization code, client credentials, device code?
  • •Focus areas: Any known concerns or specific flows to prioritize?

2. Identify OAuth Components

Locate in the codebase:

  • •Authorization request construction / handling
  • •Token endpoint requests / responses
  • •Redirect URI registration and validation
  • •PKCE implementation (code_verifier / code_challenge)
  • •Refresh token storage and rotation
  • •Token validation and audience checks
  • •Client authentication mechanisms
  • •State / nonce parameter handling

3. Evaluate Against Checklist

Work through the checklist below, rating each applicable item:

  • •✅ Compliant — Requirement fully satisfied
  • •⚠️ Partial — Met with caveats or gaps
  • •❌ Non-compliant — Violated or missing
  • •➖ N/A — Doesn't apply to this role/type
  • •❓ Unknown — Cannot determine from code inspection

See rfc9700-requirements.md for full requirement text and RFC section references. See attack-patterns.md for attack scenarios and detection guidance.

4. Report Findings

Structure the report as:

  1. •Summary — Overall posture, critical issues count
  2. •Scope — Role, client type, flows evaluated
  3. •Critical Findings — MUST/MUST NOT violations (highest priority)
  4. •Recommendations — SHOULD deviations worth fixing
  5. •Detailed Analysis — Section-by-section findings with code references

Cite both RFC sections (RFC 9700 §2.1) and code locations (src/oauth.rs:142).

Quick-Reference Checklist

Deprecated Grants

#RequirementLevelRFC §
D1Resource owner password credentials grant not usedMUST NOT2.4
D2Implicit grant (response_type=token) not usedSHOULD NOT2.1.2

Redirect URI Validation

#RequirementLevelRFC §
R1Exact string matching on redirect URIs (no patterns/wildcards)MUST2.1, 4.1
R2No open redirectors on client endpointsMUST NOT4.11
R3No HTTP scheme for authorization responses (except native loopback)MUST NOT2.1
R4AS rejects requests with invalid client_id/redirect_uri without auto-redirectMUST NOT4.11

PKCE

#RequirementLevelRFC §
P1Public clients implement PKCEMUST2.1.1
P2Confidential clients implement PKCESHOULD2.1.1
P3AS supports PKCEMUST2.1.1
P4AS enforces code_verifier when code_challenge was presentMUST4.8
P5AS rejects code_verifier if no code_challenge in auth requestMUST4.8
P6S256 challenge method used (not plain)SHOULD2.1.1
P7Code challenge values are transaction-specific and user-agent boundMUST2.1.1

CSRF Protection

#RequirementLevelRFC §
C1Client uses PKCE, nonce (OIDC), or one-time state tokenMUST2.1, 4.7
C2State parameter invalidated after first useSHOULD4.2.4

Authorization Code Handling

#RequirementLevelRFC §
A1Authorization codes invalidated after first useMUST4.2.4
A2On code replay, revoke all tokens from that grantSHOULD4.2.4
A3Nonce validated in ID Token (confidential OIDC clients)MUST2.1.1

Token Security

#RequirementLevelRFC §
T1Sender-constrained access tokens (mTLS or DPoP)SHOULD2.2
T2Access tokens restricted to minimum privilege/scopeSHOULD2.3
T3Access tokens audience-restricted to specific RSSHOULD2.3
T4Tokens not passed in URI query parametersMUST NOT2.2

Refresh Tokens

#RequirementLevelRFC §
RT1Public client refresh tokens: sender-constrained OR rotatedMUST2.2
RT2Refresh tokens bound to scope and resource serverMUST2.2
RT3Refresh token replay detected (via constraining or rotation)MUST2.2

Client Authentication

#RequirementLevelRFC §
CA1Client authentication enforced where feasibleSHOULD2.5
CA2Asymmetric methods preferred (mTLS, private_key_jwt)RECOMMENDED2.5

Mix-Up Prevention

#RequirementLevelRFC §
M1Clients with multiple AS: use iss parameter (RFC 9207) or distinct redirect URIsMUST2.1, 4.4

Transport & Headers

#RequirementLevelRFC §
TH1End-to-end TLSRECOMMENDED2.6
TH2Reverse proxies sanitize inbound security headersMUST4.13
TH3No HTTP 307 redirects with credentialsMUST NOT4.12
TH4Referrer-Policy: no-referrer on auth endpointsRECOMMENDED4.2
TH5No third-party resources on authorization pagesSHOULD NOT4.2

In-Browser Security

#RequirementLevelRFC §
B1postMessage origin/source strictly verifiedMUST4.17
B2CORS not supported at authorization endpointMUST NOT2.6
B3CORS may be supported at token endpoint (direct-access)MAY2.6

Authorization Server Metadata

#RequirementLevelRFC §
AS1Publish metadata per RFC 8414RECOMMENDED2.6
AS2Publish code_challenge_methods_supportedSHOULD2.6
AS3Clients use metadata for configurationRECOMMENDED2.6

Example

User: "review our OAuth client implementation for security"

  1. •Ask: "Is this a public or confidential client? Does it use multiple authorization servers?"
  2. •Locate auth flow: redirect URI handling, PKCE generation, token storage
  3. •Walk through checklist focusing on client requirements (R1–R4, P1/P2, C1, T4, RT1–RT3)
  4. •Check for deprecated grants (D1, D2)
  5. •Report findings with code locations and RFC section citations