Bug with accessing LTI tool's public key set?

[svickers2]

My explorations suggest that Canvas is failing to find a public key from a URL which returns a JWK Set with a content-type header of "application/jwk-set+json" as per the JSON Web Key (JWK) spec (see https://datatracker.ietf.org/doc/html/rfc7517).  I get an error of

{"errors":{"jwt":[{"attribute":"jwt","type":"JSON::JWK::Set::KidNotFound","message":"JSON::JWK::Set::KidNotFound"},{"attribute":"jwt","type":"JWT verification failure","message":"JWT verification failure"}]}}

When the content-type header used by the public key endpoint is "application/json" the error does not occur.

Has anyone else encountered this issue?

Thanks.

[matthew_buckett]

We use `application/json` on our JWK URLs and as you says that appears to work correctly, I haven't tried switching to `application/jwk-set+json`. Looking in RFC 7517 it does define the new content types in section 8 of the RFC https://datatracker.ietf.org/doc/html/rfc7517#section-8.5, however it only states "which can be used to indicate that the content is a JWK or a JWK Set".

The RFC does specify that a content type MUST be used if using and encrypted JWKS, but as you're just sharing public keys there's no need for the encryption.

Checking other services it doesn't look like anyone else big uses this MIME type for the JWKS:

❯ curl -sv https://canvas.instructure.com/api/lti/security/jwks 2>&1 | grep -i content-type:
< content-type: application/json; charset=utf-8

❯ curl -sv https://www.googleapis.com/oauth2/v3/certs 2>&1 | grep -i content-type:
< content-type: application/json; charset=UTF-8

❯ curl -sv https://login.microsoftonline.com/common/discovery/v2.0/keys 2>&1 | grep -i content-type:
< Content-Type: application/json; charset=utf-8

❯ curl -sv https://www.facebook.com/.well-known/oauth/openid/jwks/ 2>&1 | grep -i content-type:
< content-type: application/json; charset=utf-8

So it looks like most people just use `application/json` for the content-type header.

[matthew_buckett]

Supplying an `Accept: application/jwk-set+json` to encourage services to return a different `Content-Type` doesn't affect the results.

[matthew_buckett]

One more thing is the IMS LTI Reference Tool also looks to return JWKS as `application/json`:

❯ curl -H 'Accept: application/jwk-set+json' -Sv https://lti-ri.imsglobal.org/platforms/2594/platform_keys/2392.json 2>&1 | grep -i content-type:
< content-type: application/json; charset=utf-8

[svickers2]

Thanks @matthew_buckett .  So we both seem to be in agreement that the content-type of application/jwk-set+json is valid, albeit not in widespread use, so surely Canvas should accept it when accessing a public key set, rather than generating an error.  That way, those tools which are using it can continue doing so, rather than having to change or use a proxy URL to workaround it.  So how about it Instructure?

[matthew_buckett]

Yeah it would be good if Canvas just acceped it. Out of interest what's the tool that's outputting the JWKS with a MIME type of `application/jwk-set+json`?

[svickers2]

I have been using application/jwk-set+json with my own tools, including the saLTIre test tool.  Canvas is the only platform with which I have encountered an issue when doing so and its error message could be a little more helpful.  I do not understand why Canvas chooses to be so prescriptive over the content-type header; if the body includes a valid public key set, why not just generate a warning message over the content-type header?  Perhaps there is a security issue here, in which case, the list of permitted content-type header values needs to be extended.  That is my view anyway.