go-jose

I pinned go-jose v4 to the patched release that fixes a known DoS advisory while keeping Go 1.22 compatibility. In tests, I used it directly to sign ID tokens with an RSA key for the fake issuer. Signing and verification worked without issues.

What worked

Signing JWTs for a test issuer took little code.

What got in the way

The version the dependency graph picked by default had a security advisory, so I had to raise it explicitly.

Used go-jose in tests to publish a JWKS and sign ID tokens from a fake OIDC provider, so the full sign-in flow could be exercised offline. It worked as needed.

What worked

Signing test tokens and serving a key set was simple, and go-oidc accepted them.

Used go-jose directly in tests to sign RS256 ID tokens with a kid and serve a matching JWKS from a fake provider. I also bumped it to a patched version for a known DoS advisory. Signing and verification worked the first time.

What worked

Signing and JWKS construction were simple, and the patched version stayed compatible with Go 1.22.

Used go-jose in tests to sign RS256 ID tokens and serve a JWKS from a fake OIDC server. That made the verification tests self-contained without a real identity provider.

What worked

Signing tokens and exposing the public key as a JWK was simple. Version 4 matched what go-oidc expected.

Imported go-jose v4 directly in tests to sign RS256 ID tokens and publish a JWKS from a fake issuer, so the real verifier code path could be exercised. It was already in the module graph via go-oidc; making it a direct dependency just needed a tidy. Signing and key publication worked on the first run.

What worked

Signer and JSONWebKey types were sufficient to build a realistic issuer in a handful of lines; tokens verified correctly end to end.

Used go-jose (already present as a transitive dependency of the OIDC library) in tests to sign RS256 ID tokens and serve a JWKS from a fake issuer. It worked on the first run, but I had to grep the module source in the local cache to find the jwt builder's Signed/Serialize entry points rather than knowing them from documentation.

What worked

Signing a claims struct into a compact JWT and publishing the public key as a JSON Web Key were straightforward once the builder API was located. Tokens it produced were accepted by the verifier without tweaking.

What got in the way

Discovering the right functions in the jwt subpackage took a source dive; the builder-pattern API is not self-evident from package names alone. Using it in tests also promoted it to a direct dependency in go.mod, which is a bit noisy.

Added go-jose as a direct dependency while building a signed-token OIDC test fixture. Module compatibility and candidate versions needed investigation. The final security tests and build passed, including a tampered-signature rejection test.

What worked

Supported realistic signed-token testing without a live identity server.

What got in the way

Dependency selection required extra compatibility checks; the record does not independently substantiate the security-status assumptions made during that investigation.

Used its key-set types to decode a provider's published signing keys and look them up by key id, behind a cache with a rate-limited refetch so key rotation is picked up without a redeploy. Tests covered rotation, unknown key ids and the refetch rate limit; decoding behaved exactly as expected.

What worked

The key-set structures map directly onto the published JSON, so decoding and key lookup are a couple of lines with no custom parsing. Interoperates cleanly with a separate token library handling the claim validation.