Allow to Check expiration of JWT Token

[aryanmehrotra]

Currently, Oauth middleware validates if the JWT token received is valid or not but it does not check if it is expired.

As per, RFC-7519 it is optional, but how would user configure the middleware to check? Right Now, user would need to check in handler or write their own middleware - which shouldn't be the case

There should be an option while user set the JWKS url to enable these feature to validate the token expiry.

Similar to expiry the follwing should also be checked:

1. Issuer
2. Audience
3. Not Before Claim

• JTI may be can be used to manage the user sessions from the middleware itself will create a separate ticket for this.

[RahulMohanK]

@aryanmehrotra I am interested to work on this issue. Could you assign this to me ?

[aryanmehrotra]

Sure, assigning to you, before implementing can you please share the proposed solution and how user would be using it.

[Umang01-hash]

@RahulMohanK have you thought of any approach on how can we make it configurable to check if JWT token expiration check is needed? Please feel free to share it here.

[RahulMohanK]

@aryanmehrotra @Umang01-hash I have added the possible design change in oauth.go and gofr.go here. Please check the same.

[aryanmehrotra]

@RahulMohanK changing the signature of EnableOauth introduces a breaking change, we need to figure out a different approach which does not break it for existing users.

[RahulMohanK]

@aryanmehrotra To minimize the impact of breaking change the next best option is to introduce a new configuration that users can use to explicitly validate the exp of the jwt.

Users would only need to set this config, gofr will validate exp if and only if the config is set by the end user.

Name of the configuration could be JWKS_VALIDATE_EXP which can be set to true or false. Absence of the config key implies that the value is false by default.

We would only need to introduce the change in Oauth.go parseToken function.

[aryanmehrotra]

@RahulMohanK this seems to be a nice option but as user would anyway need to enable oauth using app.EnableOauth it would be better if we take variadic parameters such that it neither breaks nor allows to manage things from multiple places that is configs and the main.go - anyway if the user wished to use the configs to fetch the values they may read the values from the env file using app.Config.

Moreover, I am updating the ticket with more use cases of the same.

Should we accept an option for all these claims, or it would be better if take some map or something such that users can also provide their own claim if needed.

[danysz]

Just take in consideration that if you implement the expiration claim than it should be done including how much time is allowed after the expiration.

   The "exp" (expiration time) claim identifies the expiration time on
   or after which the JWT MUST NOT be accepted for processing.  The
   processing of the "exp" claim requires that the current date/time
   MUST be before the expiration date/time listed in the "exp" claim.
   Implementers MAY provide for some small leeway, usually no more than
   a few minutes, to account for clock skew.  Its value MUST be a number
   containing a NumericDate value.  Use of this claim is OPTIONAL.

[Umang01-hash]

@RahulMohanK are you still working on this issue?
If yes can you please give an update regarding the status of it?