-
Notifications
You must be signed in to change notification settings - Fork 18
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
decode() should not require a key? #3
Comments
it has has a key in its header
If you find a RFC which says that |
I don’t meant to use the key. I mean just a simple parse without requiring the key--the same as jwt.io is doing. Right now, if there were no http://jwt.io, would Crypt::JWT be able to do anything with that JWT without its key? I’m working on an ACME (Let’s Encrypt) client, and that service uses public keys as registration. The key is sent as in that JWT; the server parses it and extracts the key as JWK. This parse happens without first having the key. -FG
|
According to https://tools.ietf.org/html/rfc7515#section-4.1.3
|
Ah, there it is! :) -FG
|
I’m sorry I’m not being more prompt about testing changes … I literally am working nonstop currently, managing a large number of pressing obligations at work and outside. Hopefully next week things will lighten up a bit. Do you need tests/PR from me prior to releasing versions of Crypt::JWT and CryptX that incorporate the changes we’ve been discussing (thumbprints, etc.)? -FG
|
initial support for using jwk header value for verification 5af5f32 (only for JWS decoding, only works with RSA/ECC, no tests, no doc) |
Ad tests/PR - yes it will speed up the release if you can help me by submitting some tests & doc fixes. I will add a comment what I would like to have to each individual issue. |
I’ll see what I can do. These are directly useful in the project I’m doing at work, so I may actually be able to swing it as part of normal work day stuff. Thank you! -FG
|
now fixed in master |
@FGasper just FYI: since v0.23 you have to to explicitly set newly added param my ($header, $payload) = decode_jwt(token => $jws, decode_header => 1, key_from_jwk_header => 1); |
Just to clarify: is that a breaking change? |
Yes, it is a backwards incompatible change. Now you have to explicitly say that you want to use The old behaviour had some nasty security implications. |
Are these documented somewhere? They may be relevant to some other work I’ve done. Anyway, thank you for the heads-up! |
If I have the following JWT:
eyJqd2siOnsiZSI6IkFRQUIiLCJuIjoieVFJdnpEU3h2a2EzQTNhVFYzS2Yza29PeElWMjNqZGlaa1BkOU8xb3RsN0JYLWZJS2dEYk00QnBHSkxZLUhrTG5aZUxpcXgwSFpKaF94U09IVXhWNnVpLUpIU00yZkFrTnEzMHd4QzMycDZmVDk2b3RuT3ZsTEhPTVVpNEZwUFR0NDVFQmcyemlqRXRfRWNFM3g0OFJjT2ZQVGk3SDBmWnhBdXVYcmJrYmU1SHFqczVxVWp2bDFKWUdKdTA1TlItdnE2NUwyUC1oOFA5eUJBT1pRZjhRMVhBSGg1RlFQd08tQjZ3T1p6aTNjeTEtRUhXZkhpWXpxeTMxWU01ZmxIaFZ4QndWRmUyMUlINEh3WWp2SE5KMURFaEl2R2FSQTBWc09ZNlFqVUxPS19XTVlQVnExc211TmdEZThlZ1V4RnV2R2N4aWJ4NTUydHJkSHVBaWFUVGlRIiwia3R5IjoiUlNBIn0sImFsZyI6IlJTMjU2Iiwibm9uY2UiOm51bGx9.eyJjb250YWN0IjpbIm1haWx0bzpmQGcudGxkIl0sInJlc291cmNlIjoibmV3LXJlZyJ9.wrY6y0kvA3qgR38ZuAA471ygN9fmSHdfWDIayjkBKGmeGbn0f30_LQBC9FiFDFgFJ8Owyy3bOkPWvHx7yhRnP5XnEYdzNtKy4t2LyKq_JSEVQf6p1zycsVaxVLCmZ6ZbRidxIFLhbkcmu2uc4BEVGQQEj3UesccIv-AS2JCQFqK5ca-HQeaLEMntXOz5p7DYZtauYjHuXQ60i25mClm51jScJfP-wk7yYnnohGYKDinwiYlH4Nw8p4yElzWL1dI-U8fiFoxnduGaflPIZ80hkk0p7delrZt3RvmaDdu4cLJ16TgrMw_nMZfbAK0IJXByAsbej78HwIAchdzHyRPmgA
… and I put that into http://jwt.io, it parses into something useful.
I don’t see anything in this module that does this … am I missing something? (JSON::WebToken has the same issue.)
The text was updated successfully, but these errors were encountered: