Key set `AddKey` does not seem to add on `v3.0.6`

[blkt]

Hello,

I was writing some code to test a very thin layer built on top of jwt and jwk modules and was adding some tests when I ran into a problem: in my tests I generate a key pair used to sign the tokens and then I use it's public part to test validation. For some reason, the key set does not accept the key I provide.

Here's some code to reproduce the issue.

// Package main for local tests.
package main

import (
	"crypto/ecdsa"
	"crypto/elliptic"
	"crypto/rand"
	"encoding/json"
	"fmt"
	"time"

	"github.com/lestrrat-go/jwx/v3/jwa"
	"github.com/lestrrat-go/jwx/v3/jwk"
	"github.com/lestrrat-go/jwx/v3/jwt"
)

func main() {
	privateKey, err := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)
	if err != nil {
		panic("fail")
	}
	fmt.Printf("%T\n", privateKey)
	fmt.Printf("%T\n", privateKey.PublicKey)

	pubJWK, err := jwk.PublicKeyOf(&privateKey.PublicKey)
	if err != nil {
		panic(err)
	}
	err = pubJWK.Set(jwk.KeyIDKey, "test-kid")
	if err != nil {
		panic(err)
	}

	publicKeyJSON, err := json.Marshal(pubJWK)
	if err != nil {
		panic(err)
	}
	fmt.Println(string(publicKeyJSON))

	keySet := jwk.NewSet()
	err = keySet.AddKey(pubJWK)
	if err != nil {
		panic(err)
	}

	tokenString := createTestToken(time.Hour, privateKey)
	fmt.Println(tokenString)

	token, err := jwt.ParseString(tokenString,
		jwt.WithKeySet(keySet),
		jwt.WithValidate(true),
	)
	if err != nil {
		panic(err)
	}

	fmt.Printf("%+v\n", token)
}

func createTestToken(
	duration time.Duration,
	privateKey *ecdsa.PrivateKey,
) string {
	ts := time.Now()
	exp := ts.Add(duration)

	token, err := jwt.NewBuilder().
		Issuer("https://test.example.com").
		Audience([]string{"test-audience"}).
		Expiration(exp).
		IssuedAt(ts).
		NotBefore(ts).
		JwtID("test-jti").
		Subject("test-subject").
		Build()
	if err != nil {
		panic(err)
	}

	// Convert the private key to a JWK and set the kid
	privJWK, err := jwk.Import(privateKey)
	if err != nil {
		panic(err)
	}
	err = privJWK.Set(jwk.KeyIDKey, "test-kid")
	if err != nil {
		panic(err)
	}

	// Sign the token with the private key JWK (with kid)
	signed, err := jwt.Sign(token, jwt.WithKey(jwa.ES256(), privJWK))
	if err != nil {
		panic(err)
	}

	return string(signed)
}

Note that jwt.io seems to accept the printed payloads.
I assume there's no bug in the library, so could anyone clarify what am I doing wrong?

Cheers and thanks!

[lestrrat]

tl;dr:

• Set the "alg" field in the key, or
• Add a jws.WithInferAlgorithmFromKey() suboption to jwt.WithKeySet()

---

This library takes a paranoid/pedantic approach when it comes to key for verification.

In a JWS operation with JWKS, the default stance is to not trust JWK in the JWKS unless it can detect that the JWK absolutely matches the target payload. In this case, you either specify a single key to be used (via jwt.WithKey or similar), or you pass a JWKS that has a matching key ID and signature algorithm to use.

In your case you already have a "kid" on both the JWT and JWK, so they match, but you don't have an algorithm to use, so it refuses to use the key. You can tell it to infer the algorithm from the key type by doing either of the following:

pubJWK.Set(jwk.AlgorithmKey, jwa.ES256())

This will let jwx know that the key is intended for ES256, so it will use it.

jwt.ParseString(..., jwt.WithKeySet( keyset, jws.WithInferAlgorithmFromKey(true) ))

This will try all possible algorithms that it knows matches the key type. In your case it will try ES256, ES384, and ES512, in that order. This ordering will slow you down a bit if you are using ES512, because it will only match on the third try.

This default paranoid behavior is there to avoid accidentally allowing a "alg": "none" (or the like; who knows what else kind of vulnerabilities there could be) to be slipped into the token, which could somehow bypass or confuse the code to allow mismatched keys to be used.

---

Incidentally, you made me realize that I don't have an entry for this in the docs. Thank you for reminding me

[lestrrat]

Hopefully this revised example better illustrates the different failure modes and what not.

[blkt]

I see, I was under the assumption that the mandatory fields were sufficient for verification, while I understand this falls under the "security considerations" paragraph of the various RFCs.

@lestrrat thank you so much for the great explanation and code snippet, I'll close the issue! 🙇