[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FWD93VCVVNCVF5DWZJHHW":3,"skill-same:01M71FWD93VCVVNCVF5DWZJHHW":74},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":14,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M71FWD93VCVVNCVF5DWZJHHW","offensive-oauth",null,"- **Token binding**: Use DPoP or MTLS to bind tokens to clients  ### Standards and Compliance  - Follow **OAuth 2.","DCx7C5\u002Fai-marketplace","DCx7C5","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42419559?v=4","01M71C01G2AZV3NTNGWAWSHJPP","DC","01M71C01GQW6G50S2BYMS7PP3E",0,"MIT","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Foffensive-oauth\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41],"offensive oauth","offensive","OAuth","bind","cybersecurity","mtls","token","standards","tokens","use","compliance","binding","clients","2026-11-10 10:12:30",false,"---\nname: offensive-oauth\ndescription: \"- **Token binding**: Use DPoP or MTLS to bind tokens to clients  ### Standards and Compliance  - Follow **OAuth 2.\"\ndomain: cybersecurity\n---\n\n## Full Methodology\n\n# OAuth Security Testing\n\n## Shortcut\n\n- Check for improper redirect validation (open redirects)\n- Test state parameter manipulation\u002Fabsence\n- Manipulate OAuth flows to bypass authentication\n- Try URL path traversal in redirect_uri\n- Hunt for client secret leakage in source code\u002Frepos\n- Look for improper scope validation\n\n## Mechanisms\n\n- **OAuth 2.0** authorizes limited access to resources via tokens; pair with **OIDC** for identity.\n- **Core Flows**:\n  - Authorization Code (with PKCE for public clients)\n  - Client Credentials (service-to-service)\n  - Avoid Implicit and ROPC where possible\n- **Key Components**:\n  - Resource Owner (user)\n  - Client (third-party app)\n  - Authorization Server (issues tokens)\n  - Resource Server (hosts protected resources)\n  - Tokens (access and refresh)\n- **Hardening Extensions**:\n  - PAR (Pushed Authorization Requests), JAR (Request Objects), JARM (JWT-secured responses)\n  - Sender‑constrained tokens (DPoP, mTLS)\n  - `private_key_jwt` or mTLS client authentication for confidential clients\n\n### OAuth\u002FOIDC Considerations\n\n- **PKCE everywhere**: Even with confidential clients\u002Fnative apps; `code_verifier` must be required and validated.\n- **Nonce\u002Fstate binding**: For OIDC, ensure `nonce` is present and matched; `state` should be unguessable and tied to session.\n- **`redirect_uri` exact match**: Enforce exact string match against pre-registered allowlist; no wildcards\u002Fpath traversal.\n- **`aud`\u002F`azp`\u002F`iss` enforcement**: Validate tokens strictly, including clock skew and JWKS `kid` rotation behavior.\n- **Front-channel logout\u002Flogin CSRF**: Validate logout CSRF; defend forced login to attacker accounts.\n- **ID Token vs Access Token**: APIs must not accept ID tokens; check `token_type` and audience.\n- **Device Code & CIBA**: Validate polling rate limits, code expiry, and binding of device\u002Fuser codes.\n- **Refresh Token Rotation**: Enforce reuse detection and global invalidation chains.\n- **PAR\u002FJAR\u002FJARM**: Use to pin exact redirect_uri and inputs and to protect front-channel parameters.\n\n### OAuth 2.1 Updates\n\n- **Implicit Flow Deprecated**: Authorization servers should not support `response_type=token`\n- **Password Grant Deprecated**: ROPC (Resource Owner Password Credentials) considered insecure\n- **PKCE Mandatory**: Required for all OAuth clients including confidential clients\n- **Exact Redirect URI Matching**: No more substring or prefix matching allowed\n- **Refresh Token Sender Constraint**: Refresh tokens should be sender-constrained via DPoP or mTLS\n\n### Financial-grade API (FAPI) Security\n\n#### FAPI 1.0 Advanced Profile\n\n- **Signed Request Objects (JAR)**: Authorization requests as signed JWTs\n- **Hybrid Flow**: Uses `response_type=code id_token` for additional security\n- **MTLS Client Authentication**: Certificate-bound tokens\n- **JARM**: JWT-secured authorization response mode\n- **Request Object Encryption**: Sensitive parameters encrypted\n\n#### FAPI 2.0 Security Profile\n\n- **Pushed Authorization Requests (PAR)**: POST request parameters to dedicated endpoint\n- **DPoP (Demonstrating Proof-of-Possession)**: Token bound to client's key pair\n- **Client Authentication**: `private_key_jwt` or MTLS required\n- **Grant Management**: Rich authorization requests and grant management API\n\n```mermaid\ngraph TD\n    User[Resource Owner] -->|Initiates flow| Client\n    Client -->|Authorization Request| AuthServer[Authorization Server]\n    AuthServer -->|Authentication| User\n    User -->|Approves access| AuthServer\n    AuthServer -->|Authorization Code| Client\n    Client -->|Code + Client Secret| AuthServer\n    AuthServer -->|Access Token| Client\n    Client -->|Access Token| ResourceServer[Resource Server]\n    ResourceServer -->|Protected Resource| Client\n\n    style User fill:#b7b,stroke:#333,color:#333\n    style Client fill:#aae,stroke:#333,color:#333\n    style AuthServer fill:#9f9,stroke:#333,color:#333\n    style ResourceServer fill:#e9a,stroke:#333,color:#333\n```\n\n## Hunt\n\n- Intercept OAuth flows with proxy (Burp\u002FZAP)\n- Manipulate redirect_uri parameters\n- Remove\u002Ftamper state parameter\n- Test PKCE implementations\n- Inspect token handling in browsers\n- Check for client secret leakage\n- Analyze scope handling logic\n- Test account linking\u002Funlinking\n- Review token validation procedures\n- Examine refresh token security\n\n#### Native\u002FMobile\n\n- Verify App Links\u002FUniversal Links to prevent hijacking callbacks.\n- Ensure OAuth proxy components in mobile apps validate issuer and JWKS; do not ship client secrets in binaries.\n\n#### SPA\u002FBrowser\n\n- Use Authorization Code + PKCE; avoid Implicit\u002FHybrid unless justified.\n- Store tokens in memory; if cookies are used, set `__Host-` prefix with `HttpOnly; Secure; SameSite`.\n\n### Authorization Code Flow\n\n- Initial authorization request has `response_type=code`\n- Request format: `\u002Fauthorization?client_id=12345&redirect_uri=https:\u002F\u002Fclient-app.com\u002Fcallback&response_type=code&scope=openid%20profile&state=ae13d489bd00e3c24`\n- Callback contains authorization code: `\u002Fcallback?code=a1b2c3d4e5f6g7h8&state=ae13d489bd00e3c24`\n- More secure, backend exchanges code for tokens\n\n```mermaid\nsequenceDiagram\n    participant User\n    participant Client\n    participant AuthServer as Authorization Server\n    participant API as Resource Server\n\n    User->>Client: 1. Click \"Login with Service\"\n    Client->>AuthServer: 2. Authorization Request (response_type=code)\n    AuthServer->>User: 3. Login & Consent\n    User->>AuthServer: 4. Approves Access\n    AuthServer->>Client: 5. Redirect with Authorization Code\n    Client->>AuthServer: 6. Token Request (code + client_secret)\n    AuthServer->>Client: 7. Access & Refresh Tokens\n    Client->>API: 8. API Request + Access Token\n    API->>Client: 9. Protected Resource\n```\n\n### Implicit Flow\n\n- Initial authorization request has `response_type=token`\n- Request format: `\u002Fauthorization?client_id=12345&redirect_uri=https:\u002F\u002Fclient-app.com\u002Fcallback&response_type=token&scope=openid%20profile&state=ae13d489bd00e3c24`\n- Access token returned directly in URL fragment: `\u002Fcallback#access_token=z0y9x8w7v6u5&token_type=Bearer&expires_in=5000&scope=openid%20profile&state=ae13d489bd00e3c24`\n- Higher vulnerability potential due to frontend token handling\n\n```mermaid\nsequenceDiagram\n    participant User\n    participant Client as Client (Browser)\n    participant AuthServer as Authorization Server\n    participant API as Resource Server\n\n    User->>Client: 1. Click \"Login with Service\"\n    Client->>AuthServer: 2. Authorization Request (response_type=token)\n    AuthServer->>User: 3. Login & Consent\n    User->>AuthServer: 4. Approves Access\n    AuthServer->>Client: 5. Redirect with Access Token in Fragment\n    Note over Client: Token stored in browser\n    Client->>API: 6. API Request + Access Token\n    API->>Client: 7. Protected Resource\n```\n\n## Vulnerabilities\n\n- **Improper redirect_uri validation**\n  - Open redirects\n  - Subdomain\u002Fpath validation bypass\n- **CSRF attacks** (missing\u002Fimproper state parameter)\n- **Token leakage** (URL fragments in referrer headers)\n- **Scope elevation** (improper authorization)\n- **Account takeover** via improper linking\u002Funlinking\n- **JWT vulnerabilities** (weak signatures, lack of validation)\n- **Client secret exposure** in source\u002Fgit repositories\n- **Authorization bypass** in misconfigured implementations\n- **Session fixation** attacks\n- **Access token theft** via XSS\u002FMan-in-the-Middle\n\n#### Authorization Code Injection \u002F Code Substitution\n\n- Attacker injects victim authorization code into attacker session to bind victim account. Mitigate with state-nonce binding and PKCE.\n\n#### Method 1: Auth Bypass in OAuth Implicit Flow\n\n- Locate POST request containing user info (email, username) and access token\n- In implicit flow, servers often don't properly validate access tokens\n- Try changing user parameters (email, username) while keeping the token\n- Potentially impersonate other users if server trusts client-provided identifiers\n\n#### Method 2: Forced Profile Linking\n\n- Target OAuth profile linking functionality\n- Check for missing `state` parameter in auth requests\n- Create CSRF attack by copying auth URL before code\u002Ftoken use\n- Deliver as direct link or embedded iframe to victim\n- Can link attacker's social media to victim's account\n\n#### Method 3: Account Hijacking via redirect_uri\n\n- Identify authorization request with redirect_uri parameter\n- Test redirect_uri manipulation (external domains or open redirects)\n- Modify redirect_uri to attacker-controlled endpoint (webhook)\n- Deliver modified auth URL to victim to capture their authorization code\n- Use stolen code to complete OAuth flow and access victim's account\n\n## Methodologies\n\n- **Tools**:\n  - Burp Suite (OAuth Scanner extension)\n  - OWASP ZAP\n  - OAuth 2.0 Threat Model Toolkit\n  - Postman for API testing\n  - JWT_Tool for token analysis\n  - OAuthSecurity Cheatsheet Scanner\n- **Techniques**:\n  - Flow manipulation\n  - Parameter tampering\n  - Token analysis\n  - Replay attacks\n  - Social engineering (phishing for tokens)\n  - DPoP proof validation testing\n  - MTLS certificate validation testing\n  - PAR endpoint exploitation\n  - Token exchange flow testing\n\n## Chaining and Escalation\n\n### OAuth → Full Account Takeover\n\n1. **Open Redirect → Authorization Code Theft**:\n   - Discover open redirect on trusted domain\n   - Craft OAuth flow with redirect_uri pointing to open redirect\n   - Victim clicks malicious link, completes OAuth flow\n   - Authorization code redirected through open redirect to attacker\n   - Attacker exchanges code for access token\n\n2. **CSRF → Account Linking Attack**:\n   - Initiate OAuth flow to link social account\n   - Capture authorization callback URL before code is used\n   - Deliver URL to victim via CSRF\n   - Victim's account linked to attacker's social account\n   - Attacker logs in with social account to access victim's account\n\n3. **XSS → Token Theft**:\n   - Find XSS vulnerability on application\n   - Inject script to steal access tokens from localStorage\n   - Use stolen tokens to access victim's API resources\n   - If refresh tokens stolen, maintain persistent access\n\n### OAuth → Lateral Movement\n\n1. **Token Exchange → Service Impersonation**:\n   - Obtain low-privilege access token\n   - Use RFC 8693 token exchange to request token for different service\n   - Weak validation allows unauthorized service access\n   - Move laterally across microservices\n\n2. **Scope Elevation → Privilege Escalation**:\n   - Obtain token with limited scope\n   - Manipulate refresh token exchange to request broader scopes\n   - Weak scope validation grants elevated permissions\n   - Access privileged API endpoints\n\n3. **IdP Confusion → Cross-Tenant Access**:\n   - Multi-tenant application with multiple IdPs\n   - Obtain authorization code from Tenant A's IdP\n   - Exchange code at Tenant B's token endpoint\n   - Weak issuer validation grants cross-tenant access\n\n### OAuth → Backend Exploitation\n\n1. **JWT Algorithm Confusion → Signature Bypass**:\n   - Obtain valid JWT access token\n   - Change algorithm from RS256 to HS256\n   - Sign token with public key (treating it as HMAC secret)\n   - Backend fails to validate algorithm properly\n   - Forge arbitrary tokens for privilege escalation\n\n2. **SSRF via redirect_uri → Internal Service Access**:\n   - OAuth provider allows internal redirect_uri\n   - Set redirect_uri to internal service (http:\u002F\u002F169.254.169.254)\n   - Authorization response sent to internal service\n   - Use to access cloud metadata or internal APIs\n\n3. **Token Replay → Session Hijacking**:\n   - Capture access token via network sniffing or logs\n   - Token not properly bound to client (no DPoP\u002FMTLS)\n   - Replay token from attacker's system\n   - Hijack victim's session and access resources\n\n## Remediation Recommendations\n\n### OAuth 2.1 \u002F Modern Implementation\n\n- **Implement OAuth 2.1**: Adopt latest security recommendations\n  - Deprecate Implicit and Password grants\n  - Require PKCE for all clients (public and confidential)\n  - Enforce exact redirect_uri matching\n  - Implement refresh token rotation with reuse detection\n\n- **Enforce state parameter**: Always required, cryptographically random, single-use\n- **Validate token claims strictly**:\n  - `aud` (audience): Must match resource server\n  - `iss` (issuer): Verify against known issuers\n  - `exp` (expiration): Enforce with clock skew tolerance (max 60s)\n  - `nbf` (not before): Validate if present\n\n- **Secure token storage**:\n  - Never use localStorage (XSS vulnerable)\n  - Use httpOnly cookies with `__Host-` prefix or memory-only storage\n  - Set proper cookie flags: `HttpOnly; Secure; SameSite=Strict`\n\n### Advanced Security Features\n\n- **Implement PAR (Pushed Authorization Requests)**: POST parameters to `\u002Fpar` endpoint\n- **Use DPoP (Demonstrating Proof-of-Possession)**: Bind access tokens to client's public key\n- **Implement MTLS for confidential clients**: Certificate-bound access tokens\n- **Use JAR (JWT-secured Authorization Request)**: Sign authorization request parameters\n- **Consider JARM (JWT-secured Authorization Response)**: Signed authorization responses\n\n### Token Management\n\n- **Short-lived access tokens**: 5-15 minutes maximum\n- **Refresh token rotation**: Issue new refresh token on each use\n- **Refresh token reuse detection**: Revoke entire token family on reuse\n- **Token binding**: Use DPoP or MTLS to bind tokens to clients\n\n### Standards and Compliance\n\n- Follow **OAuth 2.1** (draft) guidance\n- Implement **FAPI** if dealing with financial data\n- Follow **RFC 6819** OAuth threat model\n- Adopt **RFC 8252** for native apps\n- Consider **RFC 8693** for secure token exchange\n- Implement **RFC 9449** for DPoP\n\n### Regular Security Practices\n\n- Rotate signing keys regularly (every 6-12 months)\n- Implement JWKS with short TTL (\u003C 1 hour)\n- Pin trusted issuers in client configuration\n- Conduct regular OAuth security audits\n- Keep libraries and dependencies updated\n","## Full Methodology\n\n# OAuth Security Testing\n\n## Shortcut\n\n- Check for improper redirect validation (open redirects)\n- Test state parameter manipulation\u002Fabsence\n- Manipulate OAuth flows to bypass authentication\n- Try URL path traversal in redirect_uri\n- Hunt for client secret leakage in source code\u002Frepos\n- Look for improper scope validation\n\n## Mechanisms\n\n- **OAuth 2.0** authorizes limited access to resources via tokens; pair with **OIDC** for identity.\n- **Core Flows**:\n  - Authorization Code (with PKCE for public clients)\n  - Client Credentials (service-to-service)\n  - Avoid Implicit and ROPC where possible\n- **Key Components**:\n  - Resource Owner (user)\n  - Client (third-party app)\n  - Authorization Server (issues tokens)\n  - Resource Server (hosts protected resources)\n  - Tokens (access and refresh)\n- **Hardening Extensions**:\n  - PAR (Pushed Authorization Requests), JAR (Request Objects), JARM (JWT-secured responses)\n  - Sender‑constrained tokens (DPoP, mTLS)\n  - `private_key_jwt` or mTLS client authentication for confidential clients\n\n### OAuth\u002FOIDC Considerations\n\n- **PKCE everywhere**: Even with confidential clients\u002Fnative apps; `code_verifier` must be required and validated.\n- **Nonce\u002Fstate binding**: For OIDC, ensure `nonce` is present and matched; `state` should be unguessable and tied to session.\n- **`redirect_uri` exact match**: Enforce exact string match against pre-registered allowlist; no wildcards\u002Fpath traversal.\n- **`aud`\u002F`azp`\u002F`iss` enforcement**: Validate tokens strictly, including clock skew and JWKS `kid` rotation behavior.\n- **Front-channel logout\u002Flogin CSRF**: Validate logout CSRF; defend forced login to attacker accounts.\n- **ID Token vs Access Token**: APIs must not accept ID tokens; check `token_type` and audience.\n- **Device Code & CIBA**: Validate polling rate limits, code expiry, and binding of device\u002Fuser codes.\n- **Refresh Token Rotation**: Enforce reuse detection and global invalidation chains.\n- **PAR\u002FJAR\u002FJARM**: Use to pin exact redirect_uri and inputs and to protect front-channel parameters.\n\n### OAuth 2.1 Updates\n\n- **Implicit Flow Deprecated**: Authorization servers should not support `response_type=token`\n- **Password Grant Deprecated**: ROPC (Resource Owner Password Credentials) considered insecure\n- **PKCE Mandatory**: Required for all OAuth clients including confidential clients\n- **Exact Redirect URI Matching**: No more substring or prefix matching allowed\n- **Refresh Token Sender Constraint**: Refresh tokens should be sender-constrained via DPoP or mTLS\n\n### Financial-grade API (FAPI) Security\n\n#### FAPI 1.0 Advanced Profile\n\n- **Signed Request Objects (JAR)**: Authorization requests as signed JWTs\n- **Hybrid Flow**: Uses `response_type=code id_token` for additional security\n- **MTLS Client Authentication**: Certificate-bound tokens\n- **JARM**: JWT-secured authorization response mode\n- **Request Object Encryption**: Sensitive parameters encrypted\n\n#### FAPI 2.0 Security Profile\n\n- **Pushed Authorization Requests (PAR)**: POST request parameters to dedicated endpoint\n- **DPoP (Demonstrating Proof-of-Possession)**: Token bound to client's key pair\n- **Client Authentication**: `private_key_jwt` or MTLS required\n- **Grant Management**: Rich authorization requests and grant management API\n\n```mermaid\ngraph TD\n    User[Resource Owner] -->|Initiates flow| Client\n    Client -->|Authorization Request| AuthServer[Authorization Server]\n    AuthServer -->|Authentication| User\n    User -->|Approves access| AuthServer\n    AuthServer -->|Authorization Code| Client\n    Client -->|Code + Client Secret| AuthServer\n    AuthServer -->|Access Token| Client\n    Client -->|Access Token| ResourceServer[Resource Server]\n    ResourceServer -->|Protected Resource| Client\n\n    style User fill:#b7b,stroke:#333,color:#333\n    style Client fill:#aae,stroke:#333,color:#333\n    style AuthServer fill:#9f9,stroke:#333,color:#333\n    style ResourceServer fill:#e9a,stroke:#333,color:#333\n```\n\n## Hunt\n\n- Intercept OAuth flows with proxy (Burp\u002FZAP)\n- Manipulate redirect_uri parameters\n- Remove\u002Ftamper state parameter\n- Test PKCE implementations\n- Inspect token handling in browsers\n- Check for client secret leakage\n- Analyze scope handling logic\n- Test account linking\u002Funlinking\n- Review token validation procedures\n- Examine refresh token security\n\n#### Native\u002FMobile\n\n- Verify App Links\u002FUniversal Links to prevent hijacking callbacks.\n- Ensure OAuth proxy components in mobile apps validate issuer and JWKS; do not ship client secrets in binaries.\n\n#### SPA\u002FBrowser\n\n- Use Authorization Code + PKCE; avoid Implicit\u002FHybrid unless justified.\n- Store tokens in memory; if cookies are used, set `__Host-` prefix with `HttpOnly; Secure; SameSite`.\n\n### Authorization Code Flow\n\n- Initial authorization request has `response_type=code`\n- Request format: `\u002Fauthorization?client_id=12345&redirect_uri=https:\u002F\u002Fclient-app.com\u002Fcallback&response_type=code&scope=openid%20profile&state=ae13d489bd00e3c24`\n- Callback contains authorization code: `\u002Fcallback?code=a1b2c3d4e5f6g7h8&state=ae13d489bd00e3c24`\n- More secure, backend exchanges code for tokens\n\n```mermaid\nsequenceDiagram\n    participant User\n    participant Client\n    participant AuthServer as Authorization Server\n    participant API as Resource Server\n\n    User->>Client: 1. Click \"Login with Service\"\n    Client->>AuthServer: 2. Authorization Request (response_type=code)\n    AuthServer->>User: 3. Login & Consent\n    User->>AuthServer: 4. Approves Access\n    AuthServer->>Client: 5. Redirect with Authorization Code\n    Client->>AuthServer: 6. Token Request (code + client_secret)\n    AuthServer->>Client: 7. Access & Refresh Tokens\n    Client->>API: 8. API Request + Access Token\n    API->>Client: 9. Protected Resource\n```\n\n### Implicit Flow\n\n- Initial authorization request has `response_type=token`\n- Request format: `\u002Fauthorization?client_id=12345&redirect_uri=https:\u002F\u002Fclient-app.com\u002Fcallback&response_type=token&scope=openid%20profile&state=ae13d489bd00e3c24`\n- Access token returned directly in URL fragment: `\u002Fcallback#access_token=z0y9x8w7v6u5&token_type=Bearer&expires_in=5000&scope=openid%20profile&state=ae13d489bd00e3c24`\n- Higher vulnerability potential due to frontend token handling\n\n```mermaid\nsequenceDiagram\n    participant User\n    participant Client as Client (Browser)\n    participant AuthServer as Authorization Server\n    participant API as Resource Server\n\n    User->>Client: 1. Click \"Login with Service\"\n    Client->>AuthServer: 2. Authorization Request (response_type=token)\n    AuthServer->>User: 3. Login & Consent\n    User->>AuthServer: 4. Approves Access\n    AuthServer->>Client: 5. Redirect with Access Token in Fragment\n    Note over Client: Token stored in browser\n    Client->>API: 6. API Request + Access Token\n    API->>Client: 7. Protected Resource\n```\n\n## Vulnerabilities\n\n- **Improper redirect_uri validation**\n  - Open redirects\n  - Subdomain\u002Fpath validation bypass\n- **CSRF attacks** (missing\u002Fimproper state parameter)\n- **Token leakage** (URL fragments in referrer headers)\n- **Scope elevation** (improper authorization)\n- **Account takeover** via improper linking\u002Funlinking\n- **JWT vulnerabilities** (weak signatures, lack of validation)\n- **Client secret exposure** in source\u002Fgit repositories\n- **Authorization bypass** in misconfigured implementations\n- **Session fixation** attacks\n- **Access token theft** via XSS\u002FMan-in-the-Middle\n\n#### Authorization Code Injection \u002F Code Substitution\n\n- Attacker injects victim authorization code into attacker session to bind victim account. Mitigate with state-nonce binding and PKCE.\n\n#### Method 1: Auth Bypass in OAuth Implicit Flow\n\n- Locate POST request containing user info (email, username) and access token\n- In implicit flow, servers often don't properly validate access tokens\n- Try changing user parameters (email, username) while keeping the token\n- Potentially impersonate other users if server trusts client-provided identifiers\n\n#### Method 2: Forced Profile Linking\n\n- Target OAuth profile linking functionality\n- Check for missing `state` parameter in auth requests\n- Create CSRF attack by copying auth URL before code\u002Ftoken use\n- Deliver as direct link or embedded iframe to victim\n- Can link attacker's social media to victim's account\n\n#### Method 3: Account Hijacking via redirect_uri\n\n- Identify authorization request with redirect_uri parameter\n- Test redirect_uri manipulation (external domains or open redirects)\n- Modify redirect_uri to attacker-controlled endpoint (webhook)\n- Deliver modified auth URL to victim to capture their authorization code\n- Use stolen code to complete OAuth flow and access victim's account\n\n## Methodologies\n\n- **Tools**:\n  - Burp Suite (OAuth Scanner extension)\n  - OWASP ZAP\n  - OAuth 2.0 Threat Model Toolkit\n  - Postman for API testing\n  - JWT_Tool for token analysis\n  - OAuthSecurity Cheatsheet Scanner\n- **Techniques**:\n  - Flow manipulation\n  - Parameter tampering\n  - Token analysis\n  - Replay attacks\n  - Social engineering (phishing for tokens)\n  - DPoP proof validation testing\n  - MTLS certificate validation testing\n  - PAR endpoint exploitation\n  - Token exchange flow testing\n\n## Chaining and Escalation\n\n### OAuth → Full Account Takeover\n\n1. **Open Redirect → Authorization Code Theft**:\n   - Discover open redirect on trusted domain\n   - Craft OAuth flow with redirect_uri pointing to open redirect\n   - Victim clicks malicious link, completes OAuth flow\n   - Authorization code redirected through open redirect to attacker\n   - Attacker exchanges code for access token\n\n2. **CSRF → Account Linking Attack**:\n   - Initiate OAuth flow to link social account\n   - Capture authorization callback URL before code is used\n   - Deliver URL to victim via CSRF\n   - Victim's account linked to attacker's social account\n   - Attacker logs in with social account to access victim's account\n\n3. **XSS → Token Theft**:\n   - Find XSS vulnerability on application\n   - Inject script to steal access tokens from localStorage\n   - Use stolen tokens to access victim's API resources\n   - If refresh tokens stolen, maintain persistent access\n\n### OAuth → Lateral Movement\n\n1. **Token Exchange → Service Impersonation**:\n   - Obtain low-privilege access token\n   - Use RFC 8693 token exchange to request token for different service\n   - Weak validation allows unauthorized service access\n   - Move laterally across microservices\n\n2. **Scope Elevation → Privilege Escalation**:\n   - Obtain token with limited scope\n   - Manipulate refresh token exchange to request broader scopes\n   - Weak scope validation grants elevated permissions\n   - Access privileged API endpoints\n\n3. **IdP Confusion → Cross-Tenant Access**:\n   - Multi-tenant application with multiple IdPs\n   - Obtain authorization code from Tenant A's IdP\n   - Exchange code at Tenant B's token endpoint\n   - Weak issuer validation grants cross-tenant access\n\n### OAuth → Backend Exploitation\n\n1. **JWT Algorithm Confusion → Signature Bypass**:\n   - Obtain valid JWT access token\n   - Change algorithm from RS256 to HS256\n   - Sign token with public key (treating it as HMAC secret)\n   - Backend fails to validate algorithm properly\n   - Forge arbitrary tokens for privilege escalation\n\n2. **SSRF via redirect_uri → Internal Service Access**:\n   - OAuth provider allows internal redirect_uri\n   - Set redirect_uri to internal service (http:\u002F\u002F169.254.169.254)\n   - Authorization response sent to internal service\n   - Use to access cloud metadata or internal APIs\n\n3. **Token Replay → Session Hijacking**:\n   - Capture access token via network sniffing or logs\n   - Token not properly bound to client (no DPoP\u002FMTLS)\n   - Replay token from attacker's system\n   - Hijack victim's session and access resources\n\n## Remediation Recommendations\n\n### OAuth 2.1 \u002F Modern Implementation\n\n- **Implement OAuth 2.1**: Adopt latest security recommendations\n  - Deprecate Implicit and Password grants\n  - Require PKCE for all clients (public and confidential)\n  - Enforce exact redirect_uri matching\n  - Implement refresh token rotation with reuse detection\n\n- **Enforce state parameter**: Always required, cryptographically random, single-use\n- **Validate token claims strictly**:\n  - `aud` (audience): Must match resource server\n  - `iss` (issuer): Verify against known issuers\n  - `exp` (expiration): Enforce with clock skew tolerance (max 60s)\n  - `nbf` (not before): Validate if present\n\n- **Secure token storage**:\n  - Never use localStorage (XSS vulnerable)\n  - Use httpOnly cookies with `__Host-` prefix or memory-only storage\n  - Set proper cookie flags: `HttpOnly; Secure; SameSite=Strict`\n\n### Advanced Security Features\n\n- **Implement PAR (Pushed Authorization Requests)**: POST parameters to `\u002Fpar` endpoint\n- **Use DPoP (Demonstrating Proof-of-Possession)**: Bind access tokens to client's public key\n- **Implement MTLS for confidential clients**: Certificate-bound access tokens\n- **Use JAR (JWT-secured Authorization Request)**: Sign authorization request parameters\n- **Consider JARM (JWT-secured Authorization Response)**: Signed authorization responses\n\n### Token Management\n\n- **Short-lived access tokens**: 5-15 minutes maximum\n- **Refresh token rotation**: Issue new refresh token on each use\n- **Refresh token reuse detection**: Revoke entire token family on reuse\n- **Token binding**: Use DPoP or MTLS to bind tokens to clients\n\n### Standards and Compliance\n\n- Follow **OAuth 2.1** (draft) guidance\n- Implement **FAPI** if dealing with financial data\n- Follow **RFC 6819** OAuth threat model\n- Adopt **RFC 8252** for native apps\n- Consider **RFC 8693** for secure token exchange\n- Implement **RFC 9449** for DPoP\n\n### Regular Security Practices\n\n- Rotate signing keys regularly (every 6-12 months)\n- Implement JWKS with short TTL (\u003C 1 hour)\n- Pin trusted issuers in client configuration\n- Conduct regular OAuth security audits\n- Keep libraries and dependencies updated\n",{"name":5,"domain":33,"description":7},"main","a91f1293287ffa9f4f1b8f486cd6e835a1568c84","skills\u002Foffensive-oauth","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace","https:\u002F\u002Fgithub.com\u002FDCx7C5","#Python","2026-09-01 11:21:00",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add DCx7C5\u002Fai-marketplace --skill offensive-oauth",{"tool":60,"command":61},"bunx","bunx skills add DCx7C5\u002Fai-marketplace --skill offensive-oauth",{"tool":63,"command":64},"pnpm","pnpm dlx skills add DCx7C5\u002Fai-marketplace --skill offensive-oauth","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Foffensive-oauth\u002FSKILL.md",true,[68],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"index.json","REFERENCE","参考文档",558,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Foffensive-oauth\u002Findex.json",[75,100,123,145,166,182],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":42},"01M71HAPZ01KQ30RKTB0FFSQ05","services-wmi-persistence-detect","Detect WMI event subscription persistence by enumerating ActiveScriptEventConsumer, CommandLineEventConsumer, and permanent subscriptions in the WMI repository.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fservices\u002Fwmi\u002Fpersistence\u002Fdetect\u002FSKILL.md",[],[82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,33,99],"services","detect","services wmi persistence detect","wmi","persistence","de","cm","process","activescript","event","subscriptions","commandline-consumer","repository","subscription","event-subscription","t1546.003","forensics","process-forensics",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":42},"01M71HAK6JTTTS229T17WJMMCG","services-wmi-exec-exploit","Perform lateral movement across Windows networks using WMI-based remote execution techniques including Impacket wmiexec.py, CrackMapExec, and native WMI commands for stealthy post-exploitation during red team engagements.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fservices\u002Fwmi\u002Fexec\u002Fexploit\u002FSKILL.md",[],[107,82,108,85,109,110,111,33,112,113,114,115,116,117,87,118,119,120,121,122],"exploit","services wmi exec exploit","exec","remote","traffic","Bash","analysis","team","across","crackmapexec","native","command","lateral movement","read","lateral-movement","Impacket",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":42},"01M71HAG6MHKNQV8KDZKMT4886","registry-artifact-extract","Extract and analyze Windows Registry hives to uncover user activity, installed software, autostart entries, and evidence of system compromise.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fregistry\u002Fartifact\u002Fextract\u002FSKILL.md",[],[130,131,132,133,134,135,33,112,136,113,137,138,87,120,139,140,141,142,143,144],"artifact","registry","registry artifact extract","extract","evidence-collection","artifact-analysis","collection","analyze","uncover","software","activity","digital-forensics","windows-registry","regripper","sonnet",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":42},"01M71HACR4A8XTWTTSXK4124AA","processes-token-impersonate-detect","Detect Windows token impersonation and privilege abuse including SeImpersonatePrivilege exploitation via Potato attacks and token stealing techniques.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fprocesses\u002Ftoken\u002Fimpersonate\u002Fdetect\u002FSKILL.md",[],[83,152,35,153,154,155,156,88,157,33,99,158,159,160,161,162,163,164,165,87],"processes token impersonate detect","processes","attacks","windows","escalation","techniques","privilege-escalation","seimpersonate","token-impersonation","printspoofer","exploitation","potato","impersonation","via",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":42},"01M71HAABSB4Z6QFSXEG00R4RK","processes-thread-injection-detect","Detect Windows thread injection techniques including CreateRemoteThread, QueueUserAPC, NtCreateThreadEx, and thread hijacking via process memory analysis.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fprocesses\u002Fthread\u002Finjection\u002Fdetect\u002FSKILL.md",[],[173,174,83,175,153,155,176,88,177,157,33,99,113,178,179,180,181,165,87,89],"thread","processes thread injection detect","injection","memory","process-injection","api","apc-injection","thread-injection","nt-api",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":188,"publishedAt":42},"01M71HA7H311V5G14WMX58HQSS","processes-hollow-technique-detect","Detect process hollowing (RunPE) by identifying processes with mismatched image paths between PEB and VAD tree, or unmapped PE headers in memory.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fprocesses\u002Fhollow\u002Ftechnique\u002Fdetect\u002FSKILL.md",[],[189,83,153,190,176,88,191,192,33,99,193,194,195,196,197,198,87,89,199,200],"processes hollow technique detect","tree","memory-forensics","process-hollow","peb","runpe","image","pe-header","in memory","with","mismatched","headers"]