
JWT (none) — SAMPLE
SAMPLE JWT with alg=none for auth parsers and algorithm-handling tests. Published sample material only.
- File
- JWT · Jwt
- Use case
- JWT / JWKS testing· Conversion set
Unsigned and SAMPLE-signed JWT variants plus JWKS documents, published sample material only, for auth parser tests.

SAMPLE JWT with alg=none for auth parsers and algorithm-handling tests. Published sample material only.

SAMPLE JWT with alg=HS256 for auth parsers and algorithm-handling tests. Published sample material only.

SAMPLE JWT with alg=HS384 for auth parsers and algorithm-handling tests. Published sample material only.

SAMPLE JWT with alg=HS512 for auth parsers and algorithm-handling tests. Published sample material only.

SAMPLE JWT with alg=RS256 for auth parsers and algorithm-handling tests. Published sample material only.

SAMPLE JWT with alg=RS384 for auth parsers and algorithm-handling tests. Published sample material only.

SAMPLE JWT with alg=RS512 for auth parsers and algorithm-handling tests. Published sample material only.

SAMPLE HS256 JWT with a past exp claim — for expiry-validation harnesses.

Intentionally invalid JWT (truncated) for parser error-path tests.

SAMPLE JWKS document exposing the Wave G RSA public key for JWT signature verification tests.

Empty JWKS keys array for edge-case JWKS loaders.

SAMPLE OpenID Connect discovery document for OIDC client and metadata parsers.

SAMPLE OAuth 2.0 token endpoint JSON with access, refresh, and id_token fields.

SAMPLE OAuth error JSON for token-endpoint failure handling.

SAMPLE RFC 7662-style token introspection response for auth middleware tests.

SAMPLE OAuth device-authorization response for device-flow client tests.

OAuth 2.0 SAMPLE error JSON (invalid_grant) for client error-path tests.

OAuth 2.0 SAMPLE error JSON (invalid_client) for client error-path tests.

OAuth 2.0 SAMPLE error JSON (invalid_scope) for client error-path tests.

OAuth 2.0 SAMPLE error JSON (temporarily_unavailable) for client error-path tests.

OAuth 2.0 SAMPLE error JSON (insufficient_scope) for client error-path tests.

OAuth 2.0 SAMPLE error JSON (unauthorized_client) for client error-path tests.

JWT Header Claims — RS256 SAMPLE — unsigned JSON companion for claim-parser tests (not a live token).

JWT Payload — Expired SAMPLE — unsigned JSON companion for claim-parser tests (not a live token).

The SAMPLE leaf's public key as a bare SubjectPublicKeyInfo (BEGIN PUBLIC KEY) — the form JWT verifiers and most language runtimes expect when you hand them a key rather than a certificate.

A three-key JWK Set publishing the public halves of this wave's RSA, P-256, and Ed25519 keys, each with a distinct kid. It is the resolver input for every p7 JWT, so kid selection can be tested against a set that really has more than one candidate.

A JWK carrying the full x5c certificate chain and an x5t#S256 thumbprint alongside the raw n/e values. The x5c array is standard Base64 while every other JWK field is base64url — a real and frequently mis-implemented detail.

Two keys of different types published under the same kid — what a botched key rotation leaves behind. A resolver that returns the first match silently verifies against the wrong key type instead of reporting the ambiguity.

A JWK Set whose keys carry no kid at all, which RFC 7517 permits. Verifiers must then fall back to trying candidates by algorithm, and the ones that index the set by kid alone find nothing.

The full RSA private key as a JWK, including the CRT parameters p, q, dp, dq and qi. It is the input for testing JWK-to-PEM conversion, where dropping the CRT values quietly costs a large amount of signing performance.

A single P-256 public JWK. Its x and y are fixed 32-byte base64url values, left-padded when a coordinate happens to be short — the padding rule that libraries stripping leading zeroes get wrong.

An OKP-type JWK holding the Ed25519 key pair as raw 32-byte x and d values. OKP is the newest JWK key type and the one older JOSE libraries reject outright.

The symmetric HMAC secret used by this wave's HS256 tokens, expressed as an oct JWK. The secret is printed in the specs on purpose so a verifier can be wired up without guessing.

The reference token for this wave: RS256, signed by the SAMPLE leaf key, with iss, aud, iat, nbf, exp and jti all present and an expiry in 2036. Every other JWT here is a deliberate deviation from it.

A correctly signed RS256 token whose exp passed on 2020-01-01. The signature still verifies, so it isolates expiry handling from every other check — including the libraries that validate the signature and then forget to look at exp.

A valid signature over a claim set whose nbf is 2035. Many verifiers check exp diligently and skip nbf entirely, so this is the token that finds out.

The valid RS256 token with the last bit of its signature flipped. Header and payload are byte-identical to the valid twin, so any difference in outcome is entirely down to signature verification.

A perfectly well-formed RS256 signature made with the SAMPLE root key while the kid header still names the leaf key. Verifiers that trust the kid without checking the signature against that exact key accept it.

A genuinely valid RS256 signature whose kid names a key that has been rotated out of the JWK set. The right behaviour is a clean key-not-found error, not a silent fallback to whichever key happens to be first.

An unsecured JWS: alg is none and the signature segment is empty, leaving only the trailing dot. Any verifier that accepts it will accept a claim set an attacker wrote, which is why this is the first negative test to run.

The classic algorithm-confusion shape: a token that claims HS256 while its kid points at an RSA key, MACed with that key's public PEM as the shared secret. A verifier that picks its algorithm from the header rather than from the key type accepts it.

An EdDSA (Ed25519) token with a fixed 64-byte signature and the same claim set as the RS256 reference. EdDSA signing is deterministic, so this token is reproducible in a way an ES256 one could never be.

The EdDSA token with one bit of its signature flipped. Ed25519 verification either succeeds or fails with no partial credit, which makes this the cleanest possible negative case.

A symmetric HS256 token whose secret is printed in the specs and shipped as an oct JWK, so a verifier can be stood up without any key exchange. It shares its claim set with the RS256 reference token.

One payload carrying two independent signatures — RS256 and EdDSA — in the General JSON serialization that the compact form cannot express. Multi-signature handling is the part of RFC 7515 most libraries never implemented.

The single-signature flattened JSON form of the exact same RS256 token shipped in compact serialization. Both encodings must verify to the identical payload, which is the round-trip this pair is for.

A DSSE envelope whose base64 payload decodes to the SLSA v1 statement in this family — the wrapper attestation tooling actually transports. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.