In 2.4.7 we do: JwtDecoders.fromOidcIssuerLocation(auth0Properties.issuer) as NimbusJwtDecoder with an issuer that returns a JWKS without alg properties, which should be fine since is an optional property. However when we upgrade to 2.5.x we get an error: java.lang.IllegalArgumentException: Failed to find any algorithms from the JWK set
Comment From: jzheaux
Thanks for the report, @GabrielBB. I agree that the code should not require alg to be set.
However, there might be more going on here. The code has a test to confirm that alg is not required.
JWKs need to have a kty. The code first checks if an alg is set, and If not, then it uses the kty to decide a set of algorithms. It makes me wonder what the kty attribute is for each of your JWKs.
Are you able to share a sample that reproduces the issue?
Comment From: jzheaux
@GabrielBB, your payload contains elements necessary to reformulate the associated private key, which is why it's not included in the list of potential keys. It would be safer for it to only contain the public key elements.
Because it contains private key elements, I've deleted your comment just in case it's a production key. I'm not sure if deleting the comment makes the details unfindable.
Are you able to adjust the endpoint so it only returns the public key elements?
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: GabrielBB
@GabrielBB, your payload contains elements necessary to reformulate the associated private key, which is why it's not included in the list of potential keys. It would be safer for it to only contain the public key elements.
Because it contains private key elements, I've deleted your comment just in case it's a production key. I'm not sure if deleting the comment makes the details unfindable.
Are you able to adjust the endpoint so it only returns the public key elements?
@jzheaux I switched to this:
{
"keys": [
{
"kty": "RSA",
"e": "AQAB",
"kid": "my_favorite_key",
"n": "zVlk5IPWYJzX93UjMNCSblJYSHQeWzRmG7XJlNrYhX8HtgCPBH8-yGk-TxWBS84uWdT02-cTQZqPPZN0uu7XF1IlN5absaRfyxi_Ls5YWnDseHrjWeDfHAmuXCkwHQXYmEe24F45-bOp7wFMYplAt59lez1Gu9Na7-TED9Z0x4MsARVieu41IFKVbpGyIkVLzwaL08riDpNcj_QyT-NhSB4IuOVtPhD84rt1BuRJr7CVIRY3Eh9nTWYaoSZXVif_sVVCTClmthyz0sGqRDnesPipqUXnS29HjrvKQF3SUdhBKsle-c1ofTiSINoW3Y3SYtIct6vnrmXOnVgviDGaJw"
}
]
}
When running integration tests again, it doesn't throw the error but now it gets stuck, it doesn't return. It says is getting the JWKS from the issuer and it waits forever. When rolling back to 2.4.7 it works okay with this JWKS. I verified is not a problem with our OkHttp's MockWebServer by messing up the response file, the response is returned successfully. It only gets stuck when using the JWKS above.
We are following this tutorial: https://auth0.com/blog/spring-boot-authorization-tutorial-secure-an-api-java/
Comment From: jzheaux
5.5 adds an additional HTTP request - if you are using MockWebServer to test JwtDecoders, you will need to configure it for both the OIDC discovery and JWK set requests.
Or, you might consider publishing a @MockBean of JwtDecoder and Spring Security will pick that up during your tests. This would help so that your tests aren't so reliant on Spring Security internals. Or, you could mock JwtDecoders.fromIssuerLocation.
It feels like this is moving a bit into a question instead of a bug report, so I'm going to close the issue. If you can identify a way that Spring Security functionality is broken, please feel free to re-open with additional details. If you'd like to look more deeply into integration testing with Spring Security, please feel free to post a separate StackOverflow question, and I'd be happy to take a look with you.