Re: [I] bug: JWT Plugin checks for expiration claim a priori [apisix]

2025-03-13 Thread via GitHub


mikyll commented on issue #11262:
URL: https://github.com/apache/apisix/issues/11262#issuecomment-2720835439

   @akshayparseja consider that this behaviour has been around for quite some 
time, and 2.x.x version is very old, I would say "vintage" 😄
   
   Even though I agree that the jwt-auth plugin shouldn't enforce the presence 
of `exp` or `nbf` claims **_by default_**, currently this is not configurable.
   
   ## Workarounds
   
   ### Custom `jwt-auth`
   
   You could create a custom version of the `jwt-auth` plugin and do **one of 
the followings**:
   
   - don't pass the `claim_spec` parameter to `jwt:verify_jwt_obj()` function 
(see [this 
line](https://github.com/apache/apisix/blob/52d8fea3dbc93c4b59ac6682902955c6146af4ad/apisix/plugins/jwt-auth.lua#L290),
 with reference to APISIX master branch):
   
   ```lua
   jwt_obj = jwt:verify_jwt_obj(auth_secret, jwt_obj) -- Here
   core.log.info("jwt object: ", core.json.delay_encode(jwt_obj))
   ```
   
   - set `claim_specs.lifetime_grace_period = nil` (see [this 
line](https://github.com/apache/apisix/blob/52d8fea3dbc93c4b59ac6682902955c6146af4ad/apisix/plugins/jwt-auth.lua#L288),
 with reference to APISIX master branch):
   
   ```lua
   local claim_specs = jwt:get_default_validation_options(jwt_obj)
   claim_specs.lifetime_grace_period = nil -- Here
   ```
   
    Explaination
   
   The reason it works like that, is because the presence of 
`require_exp_claim` and `require_nbf_claim` (set by 
`jwt:get_default_validation_options(jwt_obj)`) and/or `lifetime_grace_period` 
in `claim_specs`, triggers the 
[`is_legacy_validation_options`](https://github.com/api7/lua-resty-jwt/blob/6a2dda8915a10fe7d46637d048705a5ee22b9029/lib/resty/jwt.lua#L752C16-L752C44)
 and makes `exp` or `nbf` required claims (see [this 
line](https://github.com/api7/lua-resty-jwt/blob/6a2dda8915a10fe7d46637d048705a5ee22b9029/lib/resty/jwt.lua#L723)).
   
   ### Custom Dependency `api7-lua-resty-jwt`
   
   Another possibility is to edit the code of `api7/lua-resty-jwt`, update the 
dependency in 
[`.rockspec`](https://github.com/apache/apisix/blob/master/apisix-master-0.rockspec)
 file and build APISIX from source (see [APISIX Docs | Building APISIX from 
source](https://apisix.apache.org/docs/apisix/building-apisix/)).
   
   But I think that's an even worse solution 😅 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



Re: [I] bug: JWT Plugin checks for expiration claim a priori [apisix]

2025-03-12 Thread via GitHub


mikyll commented on issue #11262:
URL: https://github.com/apache/apisix/issues/11262#issuecomment-2718704708

   @akshayparseja 
   
   Consider that `jwt-auth` uses a library to validate the JWT: 
[api7/lua-resty-jwt](https://github.com/api7/lua-resty-jwt).
   
   More specifically, the line of code that indicate that the JWT must include 
`exp` and `nbf` claims is this one: 
[lib/resty/jwt.lua#L723](https://github.com/api7/lua-resty-jwt/blob/6a2dda8915a10fe7d46637d048705a5ee22b9029/lib/resty/jwt.lua#L723).
   
   ```lua
   claim_spec[str_const.full_obj] = jwt_validators.require_one_of({ 
str_const.nbf, str_const.exp })
   ```
   
   Even though I agree that the presence of `exp` claim (nor `nbf`) shouldn't 
be forced, this change was **not introduced recently**, as you can see 
[here](https://github.com/api7/lua-resty-jwt/blame/6a2dda8915a10fe7d46637d048705a5ee22b9029/lib/resty/jwt.lua#L721-L723).
   
   Probably the easiest and quickest way to obtain the behaviour you want is to 
write a custom version of the `jwt-auth` plugin, which doesn't require `exp` 
claim to be present...
   
   ---
   
   However, 2.x.x is an extremely old major version, I would say "vintage" 😄 
have you considered upgrading to a more recent and supported version? 👀 
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



Re: [I] bug: JWT Plugin checks for expiration claim a priori [apisix]

2025-03-12 Thread via GitHub


akshayparseja commented on issue #11262:
URL: https://github.com/apache/apisix/issues/11262#issuecomment-2717703633

   We got around 15 teams using jwt which was a single time token given to 
them, with no exp. Now on forcing an exp alot of changes are forced, not sure 
why is exp a madnatory since it was not in 2.x.x version.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



Re: [I] bug: JWT Plugin checks for expiration claim a priori [apisix]

2024-05-20 Thread via GitHub


mikyll closed issue #11262: bug: JWT Plugin checks for expiration claim a priori
URL: https://github.com/apache/apisix/issues/11262


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



Re: [I] bug: JWT Plugin checks for expiration claim a priori [apisix]

2024-05-17 Thread via GitHub


hanqingwu commented on issue #11262:
URL: https://github.com/apache/apisix/issues/11262#issuecomment-2117272800

   Yes,  from source code and your  testcase, I think exp is a require value 
not a  optional value , default value is 86400


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]