​Expiry time in edgemicro auth token - BUG

[babuk0930]

In edgemicro-auth, JWT token is expiring by default after 108 sec.

This is what I noticed

1. In Create-OAuth-Request AssingMessage Policy, The default time is as follows.

<AssignVariable>
	<Name>token_expiry</Name>         
	<Value>108000000</Value>     
</AssignVariable> 

2. In Set-JWT-Variables javascript policy, refrenced to jsc://set-jwt-variables.js

In that we are converting to seconds

if (token_expiry !== "") { 
//set token expiry as seconds         
context.setVariable("token_expiry", (parseInt(token_expiry, 10)/1000).toString());  
}

which means token_expiry variable is now 108000 seconds

3. In next policy GenerateJWT policy, ExpiresIn is set as follows

<ExpiresIn ref="token_expiry"/> 

As per GenerateJWT Documentation, the default value is milliseconds. So here again the value is read as milliseconds. 108000 milliseconds = 108 seconds.

This makes token to expire approximately after 108 seconds.

If you decode token payload, exp value confirms it.

So Lets say if I change the time to 900000millisec (15min) at step 1 variable, it becomes 900 sec after step2. After step 3 in token it will be 0.9 sec.

And in the token payload exp is not being set at all.

Is this the expected behavior or bug?

Note: I even upgraded my edgemicro-auth with

 edgemicro upgradeauth -o [organization] -e [environment] -u [username]

[shuklaankur]

@SatKThis does appear to be a bug, if we do not specify a unit within the ExpiresIn element while generating a token the value passed is assumed to be in milliseconds. You can make an easy fix to get past this issue:

Amend the Java script set-jwt-variables.js and add the below lines of code to(the below line will do right after token_expiry value is set and within the same try block, you can the same to the catch block for completeness.

//Fixing Issue with Expiry in seconds     
context.setVariable("token_expiry_unit", context.getVariable("token_expiry")+"s");

Next change the Generate-Access-Token policy to reference the new variable (we created above) within the ExpiresIn element.

<ExpiresIn ref="token_expiry_unit"/>

This should do the trick!

[babuk0930]

I added somewhat similar type code to append s and fixed it.

[clatimer]

"JWT token is expiring by default after 1.8 sec."

Can you confirm that you are seeing tokens expire in 1.8 seconds? Later on in the post it seems to say that the tokens are expiring in 108s which is consistent with what I am seeing.

[babuk0930]

Sorry yeah it’s 108sec

But the expiry should be 108000sec as per default confi

[clatimer]

Currently the value is set in microseconds, which I agree is a bit unusual. Also the choice of 108s is also unusual. Two questions then: 1.) Would you ever envision needing to set a token expiration for increments less than one second? 2.) What would you consider to be a reasonable default for the token expiration?

[babuk0930]

If it is less than 1 sec client cannot use it.
on our side we are planning for 15 min-900 sec

[clatimer]

Agree <1s wouldn't be useful, but would you ever need to set 180.5 seconds. I can't think of a reason why you would need to, but sometimes people have surprising requirements. 15 seems reasonable for me.

[babuk0930]

Yes. What I said is even though the default setting says 108000sec the token has an expiry of 108sec.

So the configuration is wrong. Hope they fix it in next version.

Else we need to do manually the way we said on top

[clatimer]

Can you point me to docs where it states that the default value is in seconds?

[babuk0930]

I kept in above post.

As per GenerateJWT Documentation, the default value is milliseconds. So here again the value is read as milliseconds. 108000 milliseconds = 108 seconds.

What the config is doing is --

millisec is getting converted to sec in javascript. And the seconds are getting read as millisec instead of sec in generateJWT policy, which makes token expiration time to be less