During unit testing I noticed some expected behavior regarding the.
I used your code to generate a RsaJsonWebKey keypair. Once created I set the algorithm to RS512. I created a public JWK based off of that. At that point, the keypair and the JWK had the same key-id, algorithm and signature. Next in the UT, I altered the algorithm of the JWK to RS256. I expected this to fail but it still matches and validates. Granted, the key-id and most importantly, the signatures still matched. Is algorithm really necessary? Looking into the Jose4J source code, it appears it's never set to match against the JWK.
in method SimpleJwkFilter.filter()
match &= isMatch(alg, jwk.getAlgorithm()); <-- alg is never set and therefore passes isMatch
I'm assuming you're using VerificationJwkSelector (which is used by JwksVerificationKeyResolver and HttpsJwksVerificationKeyResolver). It uses SimpleJwkFilter but only tells it to use 'alg' on the JWK as a selection criteria as a disambiguation technique when a first attempt at filtering results in more than one key. See: https://bitbucket.org/b_c/jose4j/src/b577cb539b09cb691e848244dea1769c3f7921b9/src/main/java/org/jose4j/jwk/VerificationJwkSelector.java#lines-42
I ran into some cases where 'alg' was being set incorrectly in JWKS content and considering it in the initial selection was ruling out the actual verification key. The VerificationJwkSelector behavior is intended to be accommodating of improper 'alg' values.
There's one unit test from 2015 that had JWKS with problematic alg values: https://bitbucket.org/b_c/jose4j/src/b577cb539b09cb691e848244dea1769c3f7921b9/src/test/java/org/jose4j/jwk/VerificationJwkSelectorTest.java#lines-349