-
-
Notifications
You must be signed in to change notification settings - Fork 93
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
typ
validation in JWT JOSE header
#160
Comments
Hey, thanks for starting this discussion. Out of curiosity, what The The section you cited from RFC 7515 (JWS, a layer of abstraction underneath RFC 7519 (JWT)) states:
The format used in OpenID Connect is defined to be the JWS/JWE Compact Serialization. Based on this, I agree that we should relax the check to accept either However, I don't think we should ignore
I think Option 2 probably makes the most sense. Since, as you mentioned, this doesn't have obvious security implications, it's probably not worth the complexity of Option 3. |
Hey, thanks for your quick response! I think your reasoning makes sense. If you want, I can adjust the PR accordingly. The reason I stumbled upon that specific quirk in the implementation as I am currently trying to implement RFC 9068 based on this project as it seems to have a quite nice code base with sane defaults properly following the according standards. Therefore, I took a look on how the verification is done here as within RFC 9068 the check is mandatory. This is also the reason why I started with implementing Option 3 to easily check for other |
That makes sense. Since the proposed changes are to the
Cool. Are the APIs you need to do that public? I'd like to support these kinds of extensions but hopefully without becoming a general-purpose JWT library. It might even make sense to split this crate at some point so that other libraries can leverage the innards (via a lower-level crate) without adding them to the public interface of this crate. Both crates could still live in this repo as a Rust workspace, though. |
I will adjust the MR accordingly next week (unfortunately, I have no time to properly finish it until then). But I wanted to give you a short update. So far, I started implementing a verifying access tokens within your project, check out this branch. This is really a proof of concept and I am personally not sure whether this is the right approach. I tested locally to expose more of the internal API to support such a use case better, but it seems as there would be a lot of additional exports required. Actually, my first try was just to implement the Based on these changes, I implemented a proof of concept verifying access tokens in an API situation, but this code is not ready to share yet. Will do that probably later next week. |
Currently, in the verification module the
typ
header field of the JOSE header of JWT is checked.However, I am not sure why exactly as I did not find any spec warranting the comment in line 205.
I checked RFC 7515 stating "Use of this Header Parameter is OPTIONAL" and even more that the
typ
can even beJOSE
etc. Also RFC 7519 mentions that even if the header is set it is just recommended that the header should be set to "JWT".At the moment, there is no possibility builtin to turn off or change the verification. Personally, I would see three different options to improve the situation:
typ
values while defaulting toJWT
The text was updated successfully, but these errors were encountered: