What You Can Test With the Security Library

A JWT copied from a random gist, a PEM with no subject, or an OAuth JSON with inventable field names will not tell you whether your library failed. You need fixtures whose algorithm, validity, and failure mode are documented, so the assertion is about your code—not about guessing the input.

The Security category is that labelled set. Every file is SAMPLE-only material under permanent /files/security/… paths. Specs and titles say what the file is for. Older data/security paths remain shipped and unchanged; new work lives on the security hub.

Write the behaviour first. Then open Browse filtered to security or the JWT testing purpose and take the matching file.

Contract you can test	Fixture role	What to assert
Reject alg: none	JWT (none) SAMPLE	Verifier refuses unsigned tokens
Accept a known HS256 token	JWT HS256 SAMPLE	Signature verifies with the documented SAMPLE secret in specs
Accept RS256 with JWKS	JWT RS256 + JWKS RSA	kid resolves; signature verifies
Fail on expiry	JWT expired HS256	Clock-skew policy rejects expired exp
Fail on malformed structure	Intentionally invalid JWT segments	Parser returns a typed error, not a crash
Load empty JWKS	JWKS empty SAMPLE	Key lookup fails cleanly
Parse token success vs error bodies	OAuth token response / token error	Client maps access_token vs error shapes
Parse PEM / DER / chain	X.509 PEM, DER, chain twins	Subject, notBefore/notAfter, and chain order match specs
Open PKCS#12	PKCS#12 bundle SAMPLE	Bundle opens with the documented SAMPLE passphrase
Verify htpasswd variants	bcrypt / APR1 / mixed htpasswd files	Hash verify succeeds for SAMPLE users; wrong password fails
Parse CORS / CSP / HSTS text	headers subcategory	Header names/values match the documented lines (including misconfigured CORS)

HS384/HS512 and RS384/RS512 twins exist so you can assert algorithm agility without inventing tokens.

Do not treat SAMPLE private keys, passwords, or tokens as production secrets. Do not put them in a trust store you ship to users. Do not run “penetration” scenarios that need real attack payloads—the library deliberately omits those. Corrupt or invalid samples are labelled as such; expect loud failure, not silent accept.

1. Reject none and accept one HS256 token.
2. Verify one RS256 token against the RSA JWKS.
3. Reject the expired twin under your clock policy.
4. Load one PEM certificate and one PKCS#12 with the SAMPLE passphrase from specs.
5. Parse one OAuth success JSON and one error JSON.
6. Optionally verify one htpasswd line and one CSP/CORS header file.

Pin the file page URL next to the download path in CI notes so teammates see the contract, not just a blob in a cache.

Open the Security hub, filter Browse by category, or jump to jwt-testing. Text formats open in the editor; binary DER/P12 stay download-first with specs on the page. For building a broader fixture matrix across formats, see Build a reproducible file-test matrix.