Unexpected validity of access_token obtained via exchanging refresh_token

[twosevenxyz]

When exchanging a refresh_token for an access_token, I expect the resulting access_token to have a validity as defined by the application.
However, this doesn't seem to be the case..

Currently, I'm not sure where the 12-hour duration for the JWT is coming from. Is this a default value? If so, how would I override it?

[dan]

What version of fusionauth are you running?

Does the JWT have the correct duration when first issued? Is it only when a refresh token is used that the duration is incorrect?

The tenant also has some JWT duration settings, maybe the application is being incorrectly bypassed.

Looking forward to hearing your response, maybe we can track this down with repro steps and file a bug.

[twosevenxyz]

I'm running FusionAuth v1.18.8

The access_token that is first issued has the right expiry. Any access_token received via exchanging refresh_token has a 12 hour validity.
My tenant does have a 12 hour validity on the access_token. However, any tenant setting should be overridden by the application-specific setting, is it not?

[dan]

Can you try changing the tenant session to 13 or 11 hours and see if the lifetime of the second JWT changes?

Yes, the application specific setting should control, for sure.

I don't see any refresh token changes between 1.18.8 and 1.22.0, but is it possible for you to upgrade to that version and see if this behavior still occurs?

[twosevenxyz]

Changing the JWT lifetime in the tenant reflects in the lifetime of the access_token obtained by exchanging refresh_token.
For example, with the following config, here's what I get in my logs:

Application Settings

Tenant Settings

Token expires in 28475 {aud: "faa64edb-ecca-4acb-a35e-d83f395ac04e", iat: 1607337214, exp: 1607337244}
Refreshing tokens to avoid expiry {aud: "faa64edb-ecca-4acb-a35e-d83f395ac04e", iat: 1607337214, exp: 1607337244}
Token expires in 35999195 {aud: "faa64edb-ecca-4acb-a35e-d83f395ac04e", iat: 1607337215, exp: 1607373215}

[dan]

Thanks!

One last question. Are you passing the client_id to the refresh token endpoint on all requests? (I looked through the thread, but didn't see evidence either way.) If not, does doing so affect this behavior?

https://fusionauth.io/docs/v1/tech/oauth/endpoints/#refresh-token-grant-request

[twosevenxyz]

Yes, I'm explicitly passing the client_id as a request parameter as part of every request---initial login request as well as subsequent refresh token grant requests.

Is this happening because I use the Login API as opposed to OAuth API?

[dan]

I think this is a bug. For some reason the tenant settings are controlling on the refresh token exchange when the application config should take precedence.

Can you please file an issue here: https://github.com/fusionauth/fusionauth-issues/issues and reference this forum post?