InvalidKeySpecException during client authentication with signed JWT

[Lee Surprenant]

I am trying to support http://hl7.org/fhir/uv/bulkdata/STU1.0.1/authorization/index.html with keycloak and facing some trouble.

The SMART-on-FHIR community has made some public/private keypairs available for testing: one with ES384 and one with RS384.

• https://bulk-data.smarthealthit.org/keys/

When I try using these endpoints as JWKS URIs from the Keycloak console where we manage Client credentials, I get a NullPointerException from inside keycloak because these entries are missing the `use` field. Is it documented somewhere that Keycloak requires that field in JWKS URIs?

Anyway, based on this, I:

1. copied the RS384.public.json locally
2. added a use field with a value of "sig"
3. clicked "Import Certificate"
4. changed the archive format to JSON Web Key Set
5. selected the file and clicked import

It seemed to work, but when I went to use it I ran into an error that I believe is a known issue: KEYCLOAK-16702

Next, I repeated the process for the ES384.public.json file.

Once again, the upload seemed to work, but fails when I make a call and try to validate my client with a signed JWT.  I cannot tell if it is directly related to KEYCLOAK-16702 or not, but it looks and feels a bit different:

```

16:47:12,280 ERROR XNIO-1 task-5 [org.keycloak.services] KC-SERVICES0025: Error when validating client assertion

java.lang.RuntimeException: Error when loading public keys: java.lang.RuntimeException: org.keycloak.common.util.PemException: java.security.spec.InvalidKeySpecException: encoded key spec not recognized: algorithm identifier 1.2.840.10045.2.1 in key not recognised

```

Is there anything I am missing wrt support for ECDSA-based signature algorithms (ES256, ES384, and ES512) for client authentication via signed JWT?

Do you agree that it is sufficiently different from KEYCLOAK-16702 to warrant its own issue?

Would it make sense to be up front in the UI about not supporting `Import Certificate` behavior unless the algorithm is RS256?  Maybe just as a stop-gap until https://issues.redhat.com/browse/KEYCLOAK-10462 is implemented?

[Marek Posolda]

Which Keycloak version are you using? Do you have a chance to try with latest Keycloak 15.0.2? There were some improvements in this area in the recent release, so it is possible that the issue is already fixed.

If upgrade doesn't help, you can possibly try with different Java version, like OpenJDK 11 for example. I saw in the past that Oracle JDK had some issues with some algorithms.

Marek

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/bb6ce6d0-ddbd-44dd-8c01-916ebcea3018n%40googlegroups.com.

[Lee Surprenant]

I did most of my testing with Keycloak 13.0.1 but I did spin up a 15.0.2 instance just now and confirmed that, while the function has moved to a new "Keys" tab, it is still failing client authentication with both RS384 and ES384 (and in the same ways).

[Lee Surprenant]

Also, I should have mentioned that this latest run was with the latest image (quay.io/keycloak/keycloak:15.0.2) which I believe uses OpenJDK 11 already.

[Lee Surprenant]

As an additional datapoint, once I worked around the missing "use" fields in the JWKS endpoints, both RS384 and ES384 seem to be working just fine when used from a JWKS URL.

So I do think the ES384 issue is likely related to KEYCLOAK-16702.

Additionally I opened https://issues.redhat.com/browse/KEYCLOAK-19166 for your consideration.  In the latest version of Keycloak, the missing "use" field no longer causes a NPE, so it is in better shape than before.

Just let me know if you'd like me to open a separate request for informing the user that the `Import Certificate` won't work for these algorithm types. But I'd probably still need some guidance on specifically what is / is not supposed to work here...does it only work with RS256?

[Lee Surprenant]

Great news:  I was able to build and deploy `master` and with this build I can see the new JWKS field on the client Keys tab.

I am able to populate this entry with my JWKS and, with this, both my RS384 and ES384 keys are now working.
So I won't plan to open any other issues and I'm looking forward to seeing this in the next release.

[Marek Posolda]

Thanks for the confirm. Can you please close https://issues.redhat.com/browse/KEYCLOAK-19166 if it is not relevant anymore?

Thanks,

Marek

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/fdb084ed-f5d2-4f0c-8f67-6021981c8f40n%40googlegroups.com.

[Lee Surprenant]

I think it is still relevant, just a tad lower priority for me now.

There is ongoing / interesting conversation on this topic at https://chat.fhir.org/#narrow/stream/179170-smart/topic/Backend.20Services.20-.20Public.20keys/near/250837694 (signup/login required) but the summary is this:  folks are trying to profile OAuth / OIDC to improve interoperability and this particular part of JWKS has a lot of optionality.

• the public key has no key_ops or use
• the public key has key_ops but does not have use
• the public key has use but does not have key_ops
• the public key has both key_ops and use

There's a couple different parts to this:

1. what they write into this standard for trial use specification

2. what the conformance testing tool decides to include in the product

If we think that all JWKS keys should have a 'use' then I'd love a strong statement to that effect which I can point to.

If we think having a key_op of "validate" is equivalent to having a use of "sig" (as the ietf spec seems to imply) then I think implementing KEYCLOAK-19166 is important for the improved interoperability it provides with JWKS URLs that are outside of our control.

thanks,

Lee