Open santhoskumarayyappan opened 9 months ago
Is this happening in some real-world scenario? Would be curious to know what kind of JWKs are published without specifying the algorithm.
The JWA spec adds more context about the use of the alg
header. For this gem it's technically not possible to use any other keys than the ones defined in the JWA spec.
Do you have some suggestions on how to make the example better?
Hi @anakinj , yes it is happening with Azure JWKS. https://login.microsoftonline.com/common/discovery/keys
I see. So in this RSA case the key do not care about what specific algorithm to use, also now when I think about it and the JWK endpoints I've been involved in, the alg is usually not included. So it's a very fair point you are making.
Maybe it's safer for everyone to actually always try to make the user choose the algorithms that are allowed. Would you be interested in improving the example?
Unfortunately I am not sure about a generic example other than hardcoding, in my case i am dealing with Openid Connect Idtokens. So i used the 'id_token_signing_alg_values_supported' member in /.well-known/openid-configuration
I started looking at this case and the snippet you pointed out is part of a bigger example where the optional_parameters
have the alg
and 'use' attributes. So I think for the sake of this example it makes sense. It kinda illustrates that optional parameters also can be used.
In readme we have
According to the specification, The use of "alg" member in jwks is optional. This code example results in JWT::IncorrectAlgorithm, 'An algorithm must be specified' getting raised if "alg" member if not included .Can we correct this and help with best practices on specifying algorithms parameter to decode method?