Hello everybody,

For a critical project we are trying to set up OAuth token generation and validation steps using datapower IDG 2018.4.11.1 AAA policies and post processing technique. In JWT configuration generator step, we have set the validity period to 86400 seconds based on the help documentation -

Validity period

The validity period identifies the expiration time, "exp" claim. Enter a value in the range 1 - 31622400. The default value is 3600.

However, when the token is created, it is using the default value of 3600, instead of 86400. 

We also attempted generating token using web token service configuration. There the expiration time defaults to 3600, and there is no provision to customize the value. This is a critical piece of setting necessary for us to proceed with the project.

We appreciate any suggestion tor resolve this issue.
Regards
Mahesh 

------------------------------
Mahesh Dindagur
------------------------------

I recommend you open a ticket.  Sounds like you're describing a failure to use the non default expiry period.

------------------------------
Ivan Heninger
------------------------------

Thanks so much. Will follow up. 
regards
Mahesh

------------------------------
Mahesh Dindagur
------------------------------

Original Message:
Sent: Fri June 03, 2022 09:46 AM
From: Ivan Heninger
Subject: JWT / WTS - setting expiration time

I recommend you open a ticket.  Sounds like you're describing a failure to use the non default expiry period.

------------------------------
Ivan Heninger
------------------------------

I just tested JWT generation and validation and captured the <exp> values in the probe. I can state that the values for the <exp> are being set correctly based on the setting of the validity period. The first thing I would check in the date/time setting of your machine. I am using a virtual machine and the date/time was set wrong which through me off. The actual setting of <exp> is the number of seconds since the epoch (Jan 1, 1970) so if your JWT generation machine's date/time is off, or the validation machine's date/time is off, you will get unpredictable results.
I tested this on a Firmware version 2018.4.1.17.

------------------------------
Charlie Sumner
------------------------------

Thanks for the quick response. I verified the system timestamp of the physical machine, and it seems a valid time - using the network time at our enterprise. I thought the expiration time should be calculated based on current system time, and not the number of seconds since the epoch, which means, I should set a value of 86400X365X52 --> doesnt make sense to me, considering default value of 3600 seems to provide an expiry of 1 hour.

regards
Mahesh

------------------------------
Mahesh Dindagur
------------------------------

Original Message:
Sent: Fri June 03, 2022 10:52 AM
From: Charlie Sumner
Subject: JWT / WTS - setting expiration time

I just tested JWT generation and validation and captured the <exp> values in the probe. I can state that the values for the <exp> are being set correctly based on the setting of the validity period. The first thing I would check in the date/time setting of your machine. I am using a virtual machine and the date/time was set wrong which through me off. The actual setting of <exp> is the number of seconds since the epoch (Jan 1, 1970) so if your JWT generation machine's date/time is off, or the validation machine's date/time is off, you will get unpredictable results.
I tested this on a Firmware version 2018.4.1.17.

------------------------------
Charlie Sumner
------------------------------

No, I never said to change the value of validity period to the number of seconds since the epoch. I did say that the value of <exp> in the JWT itself is the number of seconds since the epoch and this is based on the current timestamp of the machine that is generating the JWT.  Please look at the value of <exp> in the generated JWT and convert that number to the date/time. If it is 1 hour from now then the <exp> value is correct. Next, change the validity period to 7200 and see if <exp> is now 2 hours from now and so on. If this value of <exp> has not changed, then please raise a ticket.

------------------------------
Charlie Sumner
------------------------------

Original Message:
Sent: Fri June 03, 2022 11:35 AM
From: Mahesh Dindagur
Subject: JWT / WTS - setting expiration time

Thanks for the quick response. I verified the system timestamp of the physical machine, and it seems a valid time - using the network time at our enterprise. I thought the expiration time should be calculated based on current system time, and not the number of seconds since the epoch, which means, I should set a value of 86400X365X52 --> doesnt make sense to me, considering default value of 3600 seems to provide an expiry of 1 hour.

regards
Mahesh

------------------------------
Mahesh Dindagur
------------------------------


Original Message:
Sent: Fri June 03, 2022 10:52 AM
From: Charlie Sumner
Subject: JWT / WTS - setting expiration time

I just tested JWT generation and validation and captured the <exp> values in the probe. I can state that the values for the <exp> are being set correctly based on the setting of the validity period. The first thing I would check in the date/time setting of your machine. I am using a virtual machine and the date/time was set wrong which through me off. The actual setting of <exp> is the number of seconds since the epoch (Jan 1, 1970) so if your JWT generation machine's date/time is off, or the validation machine's date/time is off, you will get unpredictable results.
I tested this on a Firmware version 2018.4.1.17.

------------------------------
Charlie Sumner

Thanks for the clarification. Now I understand the rationale behind the different values for exp:, nbf:, iat: attributes. I am able to verify independently using JWT validator that the expiration times are indeed different when the settings are changed. So, JWT as a post processing step in AAA configuration seems to be working as designed. I have a small concern, though. The token created as part of post-processing step is stored as authorization output in http header. This is different from the token returned from the processing rule. I will try to troubleshoot this and mark the question for closure.

Customizing Web token service for expiration time is still an open issue, which I will follow up.

Appreciate your help!

regards
Mahesh

------------------------------
Mahesh Dindagur
------------------------------

Original Message:
Sent: Fri June 03, 2022 11:51 AM
From: Charlie Sumner
Subject: JWT / WTS - setting expiration time

No, I never said to change the value of validity period to the number of seconds since the epoch. I did say that the value of <exp> in the JWT itself is the number of seconds since the epoch and this is based on the current timestamp of the machine that is generating the JWT.  Please look at the value of <exp> in the generated JWT and convert that number to the date/time. If it is 1 hour from now then the <exp> value is correct. Next, change the validity period to 7200 and see if <exp> is now 2 hours from now and so on. If this value of <exp> has not changed, then please raise a ticket.

------------------------------
Charlie Sumner
------------------------------


Original Message:
Sent: Fri June 03, 2022 11:35 AM
From: Mahesh Dindagur
Subject: JWT / WTS - setting expiration time

Thanks for the quick response. I verified the system timestamp of the physical machine, and it seems a valid time - using the network time at our enterprise. I thought the expiration time should be calculated based on current system time, and not the number of seconds since the epoch, which means, I should set a value of 86400X365X52 --> doesnt make sense to me, considering default value of 3600 seems to provide an expiry of 1 hour.

regards
Mahesh

------------------------------
Mahesh Dindagur


Original Message:
Sent: Fri June 03, 2022 10:52 AM
From: Charlie Sumner
Subject: JWT / WTS - setting expiration time

I just tested JWT generation and validation and captured the <exp> values in the probe. I can state that the values for the <exp> are being set correctly based on the setting of the validity period. The first thing I would check in the date/time setting of your machine. I am using a virtual machine and the date/time was set wrong which through me off. The actual setting of <exp> is the number of seconds since the epoch (Jan 1, 1970) so if your JWT generation machine's date/time is off, or the validation machine's date/time is off, you will get unpredictable results.
I tested this on a Firmware version 2018.4.1.17.

------------------------------
Charlie Sumner