-
Notifications
You must be signed in to change notification settings - Fork 2.8k
feat(jwt-auth): support configuring key_claim_name
#11282
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
Conversation
Features: - config param "key_claim_name" (default = "key"), so for example one could use "iss" to check the validity of the JWT; Style: - 2 blank lines between functions; - 1 blank like before "else" and "elseif"; - jwt -> JWT; - Capitalized logs and response messages; - Added description for each schema configuration parameter;
We need more eyes to improve code quality
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove the style changes and add test cases to support your fix. Thanks.
|
@shreemaan-abhishek thank you for the feedback. I understand the importance of keeping PRs focused, but I made the style changes to align with the code_style guide. Could you please clarify if:
Anyways, I'll be happy to add the necessary test cases, as soon as possible :-) |
…pentelemetry plugin (#11247)
Co-authored-by: Navendu Pottekkat <[email protected]> Co-authored-by: Abhishek Choudhary <[email protected]>
I added a new test case for feature #11276 Since the default value of the new config parameter "key_claim_name" is "key", "default behaviour" is already validated by other tests.
+ Removed external httpbin upstream in favor of local endpoint (/hello); + Cleaned code;
|
@shreemaan-abhishek
|
Co-authored-by: Traky Deng <[email protected]>
|
This pull request has been marked as stale due to 60 days of inactivity. It will be closed in 4 weeks if no further activity occurs. If you think that's incorrect or this pull request should instead be reviewed, please simply write any comment. Even if closed, you can still revive the PR at any time or discuss it on the [email protected] list. Thank you for your contributions. |
|
Hello, any news on this PR? |
| local function get_real_payload(key, auth_conf, payload, key_claim_name) | ||
| local real_payload = { | ||
| key = key, | ||
| [key_claim_name] = key, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
although the key_claim_name has changed, the value of key_claim_name will always be key. That doesn't fit into the scene. For example, if the key_claim_name is exp then the value should be the expiry time, not the key. Right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shreemaan-abhishek I'm not sure if I understood your comment correctly, in case I didn't please correct me :)
The purpose of key_claim_name parameter is just to tell in which claim the key is stored, so that the plugin can use this for the validation. For example, the company where I work uses JWTs which do not include the key claim, but do include iss instead.
The reason why I also made changes to get_real_payload() and the like, was to provide a way to generate a signed token with a custom key claim name, through the public API (otherwise I would have needed to make a test case with a hardcoded token, see line 182 of commit 2af7e156aa07ca29cf19f4934daa605eb0571902 for reference).
Addressing your comment, if key_claim_name was "exp", then no, the value shouldn't be the expiry time, but still the key. However, that would cause some problem:
- even though according to JWT standard, RFC 7519, the
expclaim is optional, the jwt-auth plugin requires it to validate the token, and returns401if it's not present (at this line):[warn] 64#64: *16957 [lua] jwt-auth.lua:442: phase_func(): failed to verify jwt: Missing one of claims - [ nbf, exp ].,
- setting
key_claim_nameto "exp" is not feasible, since that would generate a token with duplicatedexpclaim.
At most, we could handle this case by preventing the usage of "exp" and "nbf" as key_claim_name, what do you think?
|
@mikyll, please rebase with master there have been some changes in the CI. |
key_claim_name
Features: - config param "key_claim_name" (default = "key"), so for example one could use "iss" to check the validity of the JWT; Style: - 2 blank lines between functions; - 1 blank like before "else" and "elseif"; - jwt -> JWT; - Capitalized logs and response messages; - Added description for each schema configuration parameter;
I added a new test case for feature #11276 Since the default value of the new config parameter "key_claim_name" is "key", "default behaviour" is already validated by other tests.
+ Removed external httpbin upstream in favor of local endpoint (/hello); + Cleaned code;
…into jwt_key_claim_name
|
@shreemaan-abhishek I've done the rebase with master, and I also left a reply to your comment. Possible enhancements for that
|
|
This pull request has been marked as stale due to 60 days of inactivity. It will be closed in 4 weeks if no further activity occurs. If you think that's incorrect or this pull request should instead be reviewed, please simply write any comment. Even if closed, you can still revive the PR at any time or discuss it on the [email protected] list. Thank you for your contributions. |
|
Closing this since it's outdated and is being implemented in #11772 👀 |
Description
New feature:
key_claim_name(default = "key"), so for example one could use "iss" to check the validity of the JWT;(similar behaviour to Kong JWT plugin)
Fixes #11276
Checklist