Oauth data simulation

Skill kjuhwa/skills-hub/skills/workflow/oauth-data-simulation

Self-correcting knowledge corpus for Claude Code — 9 stable shape clusters, bias-correction pipeline baked into contribution flow. 47 papers, 45 techniques, 1.1k skills.

Install

npx -y skills add kjuhwa/skills-hub --skill oauth-data-simulation

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Generating realistic OAuth tokens, flow states, and scope sets for client-side simulators without a real auth server

SKILL.md

2.0 KB, 400 tokens by cl100k_base, as published. Nobody here has run it

oauth-data-simulation

Client-side OAuth simulators need deterministic-but-realistic fixture data: generate JWTs in-browser using a well-known symmetric secret ("demo-secret-do-not-use-in-prod") or an ephemeral Web Crypto–generated keypair so signatures actually verify. Populate claims with plausible values — iss: "https://auth.example.com", aud: "api://default", sub: "user_" + nanoid(8), iat: now, exp: now + 3600, plus domain-appropriate custom claims (scope, roles, tenant_id). Include a gallery of pre-seeded anomalous tokens: expired, not-yet-valid (nbf in future), wrong-audience, algorithm-confusion (alg: none), tampered-payload-valid-signature — these are the scenarios users most want to inspect.

For flow simulation, model each OAuth grant type as a state machine with explicit transitions and wire-level artifacts at each edge: /authorize request params, consent screen, redirect with code, /token POST body, token response JSON. Store the full transcript as an array of {step, timestamp, direction: 'client→as' | 'as→client', payload} entries so users can scrub through the exchange. For PKCE, generate code_verifier (43–128 char URL-safe random) and derive code_challenge via SHA-256 + base64url on the fly — don't hardcode, because users will want to change the verifier and see the challenge update.

Scope simulation should ship a realistic scope catalog (OIDC standards: openid profile email address phone offline_access plus resource-specific: read:X write:X admin:X delete:X) and a resource catalog mapping endpoints to required scopes. Then simulate consent: user-granted subset → token scope claim → API call authorization decision. Randomize partial grants to teach users that requested ≠ granted.

Gives 0 of the 12 instructions most auth identity skills give in 400 tokens

Counted across 409 of the 410 authors here whose files we hold, read 2026-08-06

hash passwords with bcrypt or argon2in 53 of 409, across 43 files
use parameterized queriesin 47 of 409, across 39 files
load SECRET_KEY from environment variablesin 23 of 409, across 14 files
validate all input server-sidein 19 of 409, across 11 files
refresh access tokens before expiryin 17 of 409, across 9 files
store tokens in httponly cookiesin 17 of 409, across 16 files
store refresh tokens securelyin 16 of 409, across 6 files
validate webhook signatures before processingin 15 of 409, across 5 files
sanitize user inputsin 15 of 409, across 9 files
implement rate limiting on auth endpointsin 14 of 409, across 9 files
encrypt sensitive data at restin 13 of 409, across 10 files
validate uploaded file extensions and sizesin 12 of 409, across 5 files

Said here and by no other author read

generate verifiable signatures using Web Crypto or symmetric secret
populate JWT claims with plausible standard and custom values
include pre-seeded anomalous tokens for inspection
model grant types as state machines with wire-level artifacts
store full flow transcript as timestamped payload entries
generate PKCE verifier and derive challenge dynamically