Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Allow secretOrPrivateKey in verify to be function(kid)
See original GitHub issueI currently use decode to get the kid, then use verify with the correct key. This could be simplified if verify would accept secretOrPrivateKey to be a function(kid) so this could be handled in one step.
I could make a PR in the coming weeks, would this be accepted?
EDIT: I just realize that function(kid) would probably fetch the key asynchronously from the AP. In that case the function would return a promise. That can only work if verify is called asynchronously. I think it’s possible to implement this backwards compatible. Perhaps in the future the whole library should be made with promises instead of callbacks? Any thoughts?
Issue Analytics
- State:
- Created 6 years ago
- Reactions:2
- Comments:8 (6 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@ziluvatar I have opened a new PR for this, which has the functionality from the original PR, but without the breaking changes. I am eager to see if this is ok.
I think it’s a bit risky. I’m not trusting the jwtClaims until the signature check has passed. The one to decide which is the issuer is the client, not the token. Otherwise anyone could put any issuer in the token and make the signature check pass. I would avoid that and just pass the jwtHeaders (or just kid).
I’m not very familiar with jwks, so what do you think?