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

How does the library work for a token that doesn't have kid in header, but only x5t? #5

Closed
Freundschaft opened this issue Jan 25, 2017 · 8 comments · Fixed by #55
Closed
Assignees

Comments

@Freundschaft
Copy link

Freundschaft commented Jan 25, 2017

I have a token with a header that has only set the x5t field, but not the kid field, as far as I can see this lib is using only the kid value? how would be the correct way to proceed with a JWT that only has X5T in the header?

as far as I can see form my well known jwks file, both values are identical there.

@Freundschaft
Copy link
Author

I believe that https://tools.ietf.org/html/rfc7515#section-6 states that all the header parameters jku, jwk, kid x5u, x5c, x5t and x5t#s256 could be used to identify the key used, am I missing something?

@larryboymi
Copy link

larryboymi commented Mar 23, 2017

I agree. I have a case with only an x5t as well. This spec refers to most of these as optional. Is there a way we could specify which header parameter to use as the key when searching via getSigningKey?

@larryboymi
Copy link

larryboymi commented Mar 23, 2017

FWIW... I added this to my promisified version of my case for now...

const getSigningKey = (kID) => // in case k5t is there while kID is not
  getSigningKeys()
  .then((keys) => keys.find(k => k.k5t === kID || k.kid === kID))

@williamdenton
Copy link

for reference here is the code block that has the problem:

const key = keys.find(k => k.kid === kid);
if (key) {
return cb(null, key);
} else {
this.logger(`Unable to find a signing key that matches '${kid}'`);
return cb(new SigningKeyNotFoundError(`Unable to find a signing key that matches '${kid}'`));
}

@stale
Copy link

stale bot commented Nov 28, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you have not received a response for our team (apologies for the delay) and this is still a blocker, please reply with additional information or just a ping. Thank you for your contribution! 🙇‍♂️

@stale stale bot added the closed:stale Issue or PR has not seen activity recently label Nov 28, 2019
@stale stale bot closed this as completed Dec 5, 2019
@williamdenton
Copy link

@damieng, could this at least be triaged by an Auth0 maintainer?

@damieng damieng reopened this Dec 5, 2019
@stale stale bot removed the closed:stale Issue or PR has not seen activity recently label Dec 5, 2019
@philmerrell
Copy link

This came up for us when trying to validate access_tokens through ADFS. For whatever reason, id_tokens have a kid, but access_tokens have x5t in the header. Not sure if this is all ADFS instances or only ours. We don't have control over the box, so this would be a great fix.

@dejan9393
Copy link
Contributor

I actually opened up #55 a while ago to allow JWT's without a KID header to pass validation

@davidpatrick davidpatrick self-assigned this Mar 18, 2020
@davidpatrick davidpatrick linked a pull request Apr 3, 2020 that will close this issue
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

Successfully merging a pull request may close this issue.

7 participants