-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
feat: add key object v5 #365
Conversation
This aims to provide backwards compatibility by guessing the algorithm for a key based on the key's contents, but it will likely fail in corner cases. If this is merged, users **SHOULD** be explicit about the algorithms they're using. i.e. Instead of $keyAsString, pass in (new JWTKey($keyAsString, 'ES384'))
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@googlebot I consent. |
Providing algorithms as 3rd parameter is marked deprecated but still needs to be used when working with JWKs? Is this still true? |
@swiffer no, it's not REQUIRED, it is possible to loop through the returned keys and create Key objects from them. This is the recommended way and i should probably update the docs with an example. |
@bshaffer as the keys array from the jwks is containing the alg for every key provided isn't it safe to rely on these and change the return value of parseKeySet to return Key objects directly? |
@swiffer we can't change the return value without tagging a new major release, so the library won't be able to make that change until the next major version, which is the plan. |
Yes, have just figured that out this moment checking the pr for 6.0 - thanks a lot. Looking forward for the release! |
Modifications to POC PR #352
Firebase\JWT\Key
objects instead of using an array of$allowed_args
. This is more secure because it ties a key to an algorithmThis prevents a certain kind of attack described in #351.
Releasing this as an optional feature in
v5
will allow libraries to require5.5^|6^
in composer when we make using theKey
objects required inv6
, and that will allow a smoother upgrade for everyone.cc @paragonie-security