跳到正文
cccskills
免费在 GitHub 公开

oauth-flow-test-author

Build-an-X for OAuth 2.0 / OIDC flow tests - authorization-code with PKCE per RFC 7636 (canonical for browser/native/mobile clients), client-credentials per RFC 6749 §1.3.4 (M2M), refresh-token rotation per RFC 9700 (token-binding + reuse-detection), state parameter for CSRF defense per RFC 6749 §10.12, nonce parameter for OIDC ID-token replay defense, scope-grant verification, redirect-URI strict matching. Use when authoring tests for any OAuth/OIDC client or resource server, regardless of the underlying IdP (Keycloak / Auth0 / Okta / mock).

中文简介正在准备中。当前显示原文说明。

testland/qa星标 13(GitHub 13 + cccskills 0)
集成工具Playwright

实测评分 未实测

查看安装方法

包含的文件(13)

  • SKILL.md9.0 KB
  • .tessl-plugin/plugin.json689 B
  • evals/partner-retires-api-keys-in-nine-days/criteria.json5.2 KB
  • evals/partner-retires-api-keys-in-nine-days/task.md9.3 KB
  • evals/pentest-finding-the-author-says-is-wrong/criteria.json5.4 KB
  • evals/pentest-finding-the-author-says-is-wrong/task.md11.8 KB
  • evals/pkce-exchange-fails-three-times-in-four/criteria.json5.9 KB
  • evals/pkce-exchange-fails-three-times-in-four/task.md9.8 KB
  • evals/red-auth-suite-turned-green-in-one-afternoon/criteria.json4.8 KB
  • evals/red-auth-suite-turned-green-in-one-afternoon/task.md12.7 KB
  • evals/thirty-day-sessions-go-live-on-monday/criteria.json5.1 KB
  • evals/thirty-day-sessions-go-live-on-monday/task.md9.4 KB
  • references/per-flow-test-recipes.md4.8 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

oauth-flow-test-author

Overview

OAuth 2.0 (RFC 6749) defines four grant types per datatracker.ietf.org/doc/html/rfc6749:

"1. Authorization Code (§1.3.1): The authorization code is obtained by using an authorization server as an intermediary between the client and resource owner. 2. Implicit (§1.3.2): The implicit grant is a simplified authorization code flow optimized for clients implemented in a browser using a scripting language such as JavaScript. 3. Resource Owner Password Credentials (§1.3.3): The resource owner password credentials (i.e., username and password) can be used directly as an authorization grant to obtain an access token. 4. Client Credentials (§1.3.4): The client credentials can be used as an authorization grant when the authorization scope is limited to protected resources under the control of the client."

Per RFC 9700 (OAuth 2.0 Security Best Current Practice, March 2025):

  • Implicit grant is deprecated.
  • Resource Owner Password Credentials grant is deprecated.
  • Authorization Code with PKCE (per datatracker.ietf.org/doc/html/rfc7636) is the canonical flow for all clients, public or confidential.

This skill is the per-flow test recipe. The canonical authorization-code + PKCE flow is authored end to end in the Worked example below; the less-common grants and negative cases live in references/per-flow-test-recipes.md.

When to use

  • Authoring tests for an OAuth 2.0 / OIDC client (web, mobile, SPA, M2M).
  • Reviewing PRs that touch auth-flow code.
  • The team needs flow-coverage independent of the IdP choice (Keycloak / Auth0 / Okta / mock).

How to use

  1. Identify the grant(s) the client uses from the flow-selection table below.
  2. Author the authorization-code + PKCE happy path (the Worked example) - the canonical flow for browser / native / mobile clients.
  3. Add the negative and secondary-grant tests each client needs (state CSRF, client-credentials, refresh-token rotation, OIDC nonce, scope-downgrade, redirect-URI) from references/per-flow-test-recipes.md.
  4. Run the end-to-end coverage checklist for every OAuth/OIDC client in scope.

Flow-selection decision surface

Client typeGrant to testRequired testsRecipe
Browser / SPA / native / mobileAuthorization Code + PKCE (S256)Happy path + state CSRF + redirect-URI + (OIDC nonce if openid)Worked example + references
Machine-to-machine (M2M)Client CredentialsHappy path; assert no refresh_tokenreferences
Any client holding a refresh tokenRefresh TokenRotation + reuse-detectionreferences
Any OIDC clientAuthorization Code + ID TokenNonce match + scope-downgradeWorked example + references
Legacy Implicit / RO-Password(none - deprecated per RFC 9700)Migrate to Auth Code + PKCE-

Worked example - authorization-code + PKCE (canonical)

Per RFC 6749 §4.1 (per rfc6749) the flow:

  1. Client directs resource owner to authorization endpoint with client_id, redirect_uri, response_type=code, scope, state (RECOMMENDED for CSRF defense per §10.12), nonce (OIDC), and PKCE params (code_challenge + code_challenge_method).
  2. Authorization server authenticates the resource owner.
  3. Server redirects back to client with the authorization code + the original state.
  4. Client requests token endpoint with grant_type=authorization_code, code, redirect_uri, client_id, and PKCE code_verifier.
  5. Server returns access token (+ refresh token + ID token if OIDC).

PKCE per RFC 7636 §4.2 (rfc7636):

"Two methods are defined:

  • plain: code_challenge = code_verifier
  • S256: code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))"

Always use S256; plain defeats the purpose of PKCE.

Test pattern (Python with requests + Playwright for browser flow):

import secrets, hashlib, base64, requests
from urllib.parse import urlparse, parse_qs

def make_pkce_pair():
    verifier = secrets.token_urlsafe(64)
    challenge = base64.urlsafe_b64encode(
        hashlib.sha256(verifier.encode("ascii")).digest()
    ).rstrip(b"=").decode("ascii")
    return verifier, challenge

def test_authz_code_pkce_flow(idp_url, client_id, redirect_uri, browser):
    verifier, challenge = make_pkce_pair()
    state = secrets.token_urlsafe(32)
    nonce = secrets.token_urlsafe(32)

    # Step 1: redirect to authorize endpoint
    authz_url = (
        f"{idp_url}/authorize?"
        f"client_id={client_id}&response_type=code&"
        f"redirect_uri={redirect_uri}&scope=openid+profile&"
        f"state={state}&nonce={nonce}&"
        f"code_challenge={challenge}&code_challenge_method=S256"
    )
    # Browser interaction (simulated via Playwright):
    page = browser.new_page()
    page.goto(authz_url)
    page.fill("#username", "alice")
    page.fill("#password", "alicepass")
    page.click("#submit")

    # Step 3: redirect lands on redirect_uri with code + state
    redirected_to = page.url
    parsed = urlparse(redirected_to)
    query = parse_qs(parsed.query)
    assert query["state"][0] == state    # RFC §10.12 CSRF defense
    code = query["code"][0]

    # Step 4: token endpoint
    token_response = requests.post(
        f"{idp_url}/token",
        data={
            "grant_type": "authorization_code",
            "code": code,
            "redirect_uri": redirect_uri,
            "client_id": client_id,
            "code_verifier": verifier,    # PKCE proof
        },
    )
    assert token_response.status_code == 200
    body = token_response.json()
    assert "access_token" in body
    assert body["token_type"] == "Bearer"

The happy path asserts the returned state matches; the negative state-mismatch test, plus the client-credentials, refresh-rotation, OIDC-nonce, scope-downgrade, and redirect-URI recipes, are in references/per-flow-test-recipes.md.

End-to-end coverage checklist

For each OAuth/OIDC client in scope:

  1. Auth-code + PKCE happy path (Worked example)
  2. State parameter validation (references)
  3. Client-credentials happy path (if M2M; references)
  4. Refresh-token rotation + reuse detection (references)
  5. OIDC nonce validation (if OIDC; references)
  6. Scope-downgrade handling (references)
  7. Redirect-URI strict matching (references)
  8. Token expiration handling (use-after-expiry returns 401)
  9. Token revocation (RFC 7009) if endpoint supports it

Anti-patterns

Anti-patternWhy it failsFix
Use PKCE plain methodDefeats PKCE; RFC 7636 §4.2 specifies S256 as recommendedAlways S256 (Worked example)
Skip state validation in the callback handlerCSRF vulnerableState CSRF negative test (references)
Hardcode redirect_uri prefix matchingSubstring match accepts evil URIsStrict equality (references)
Test only the happy pathNegative cases (mismatched state, invalid PKCE, expired token) untestedNegative tests (references)
Use Implicit or RO-Password grants in new codeDeprecated per RFC 9700Auth Code + PKCE

Limitations

  • This is a build-an-X workflow. Tests use the application's HTTP client + browser automation library; this skill is the per-flow checklist.
  • IdP-specific quirks (audience, custom auth servers, sign-in policies) layer on top - see keycloak-tests, auth0-tests, okta-tests for IdP-specific patterns.
  • RFC 9700 supersedes earlier security BCPs; pin to the latest version when authoring tests.
  • OAuth 2.1 (in-progress) consolidates the deprecations from RFC 9700; prefer 2.1 patterns when the IdP supports them.

References

  • rfc6749 - RFC 6749 OAuth 2.0 Authorization Framework
  • rfc7636 - RFC 7636 PKCE
  • IETF RFC 9700 - OAuth 2.0 Security Best Current Practice (March 2025)
  • IETF RFC 7009 - OAuth 2.0 Token Revocation
  • openid.net/specs/openid-connect-core-1_0.html - OIDC Core spec
  • references/per-flow-test-recipes.md - state CSRF, client-credentials, refresh-token rotation, OIDC nonce, scope-downgrade, and redirect-URI recipes.
  • keycloak-tests, auth0-tests, okta-tests - IdP-specific patterns
  • session-management-test-author - companion: post-auth session lifecycle

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Builds a CI gate that fails the build on **new** WCAG / a11y violations introduced by a PR while grandfathering pre-existing violations on a per-rule / per-page baseline. Aggregates verdicts from axe-core / pa11y / Lighthouse a11y / WAVE / IBM Equal Access scans. Use when a project has accumulated a11y debt and a strict "zero violations" gate would block every PR - the ratchet pattern lets the team ship while preventing regressions.

中文简介正在准备中。当前显示原文说明。

testland/qa132026年10月20日 更新

Workflow skill that builds an A/B-test validity checklist from an experiment proposal, walking the canonical design-correctness gates - pre-registered OEC/power/guardrails, randomization unit + SRM check, assignment integrity, telemetry, peeking discipline, novelty/primacy, post-experiment SRM re-check - into a per-experiment checklist + sign-off form. Use when launching, auditing, or governing an experiment. For pitfall mechanics (guardrails, peeking) see experiment-results-interpreter's references; to read an already-valid result use experiment-results-interpreter; for per-SDK harness tests use experiment-sdk-testing - this gates DESIGN, not SDK code.

中文简介正在准备中。当前显示原文说明。

testland/qa132026年10月20日 更新

The single install-flow skill: the reference contract for the PWA install flow (installability gate fields, `beforeinstallprompt` handshake, per-platform paths - Android WebAPK / iOS Share menu / Firefox no-op - and the `display-mode` post-install signal, in references/install-flow-reference.md) plus the build-an-X workflow that emits the Add-to-Home-Screen suite. Walks the four-stage timeline, emitting one test per gate cell per [web.dev/articles/install-criteria][install-criteria], the deferred-prompt → `prompt()` → `userChoice` chain per [web.dev/articles/customize-install][customize-install], the iOS Safari manual-metadata branch (`apple-touch-icon`) per [web.dev/learn/pwa/installation][learn-pwa], and the post-install `(display-mode: standalone)` MQ assertion. Output: a Playwright spec with per-stage cells plus a coverage matrix. Use when a PWA's manifest, icons, or install handler change, when install conversion drops at an unknown stage, or when triaging a flaky install assertion.

中文简介正在准备中。当前显示原文说明。

testland/qa132026年10月20日 更新

Build-an-X workflow that uses an LLM to map existing tests to spec sections - given a spec doc + the test suite, the LLM identifies which tests cover which sections, surfaces uncovered sections (gap), and recommends specific tests to add. Output is a coverage matrix per spec ID. Scope is mapping tests that already exist and naming the gaps, not authoring tests for new acceptance criteria. Use when a spec doc and a test suite both exist but nobody can say which requirements are actually covered - before a release sign-off, an audit, or a decision about where to spend the next round of test effort.

中文简介正在准备中。当前显示原文说明。

testland/qa132026年10月20日 更新

Generates tests from natural-language specs (acceptance criteria, user stories, requirements) using an LLM, with confidence scoring per test case (LLM self-assessment plus heuristics: assertion quality, naming, completeness), batching uncertain cases for human review, and integration with the team's existing test framework. Use when the user asks to generate unit tests from acceptance criteria, convert user stories to test cases, automate test creation from requirements, or augment a spec-driven test suite with AI-generated stubs that are then curated before merge.

中文简介正在准备中。当前显示原文说明。

testland/qa132026年10月20日 更新

Configures Allure Report (test-runner adapter install, `allure-results` directory wiring, `categories.json` for failure classification, `history-trend.json` retention via the copy-history-between-runs pattern), runs the Allure CLI to convert `allure-results` to a static HTML site, and uploads the report as a CI artifact. Use when the team needs richer test reporting than JUnit XML - step-level attachments, per-test history, retry tracking, and severity / epic / feature labeling across framework-agnostic adapters (pytest, Jest, JUnit, TestNG, NUnit, Mocha). As a rich static HTML report generator, it is the open-source alternative to the sunset ExtentReports (JVM/.NET per-test HTML narrative); for hosted cross-run flakiness analytics rather than a static per-run report use currents-integration.

中文简介正在准备中。当前显示原文说明。

testland/qa132026年10月20日 更新

查看 testland 的全部技能

报告此技能的问题