Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alg optional member Readme #574

Open
santhoskumarayyappan opened this issue Dec 15, 2023 · 5 comments
Open

Alg optional member Readme #574

santhoskumarayyappan opened this issue Dec 15, 2023 · 5 comments

Comments

@santhoskumarayyappan
Copy link

santhoskumarayyappan commented Dec 15, 2023

In readme we have

jwks = JWT::JWK::Set.new(jwks_hash)
jwks.filter! {|key| key[:use] == 'sig' } # Signing keys only!
algorithms = jwks.map { |key| key[:alg] }.compact.uniq
JWT.decode(token, nil, true, algorithms: algorithms, jwks: jwks)

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?

@anakinj
Copy link
Member

anakinj commented Dec 17, 2023

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?

@santhoskumarayyappan
Copy link
Author

Hi @anakinj , yes it is happening with Azure JWKS. https://login.microsoftonline.com/common/discovery/keys

@anakinj
Copy link
Member

anakinj commented Dec 17, 2023

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?

@santhoskumarayyappan
Copy link
Author

santhoskumarayyappan commented Dec 17, 2023

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

@anakinj
Copy link
Member

anakinj commented Dec 28, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants