Getting access_token returns invalid_grant after 30 days, 'Refresh token usage' is set to 'One time'

[Mathijsdb]

Hi all,

We encounter an issue with refresh tokens. Each time we get a new access token, a new refresh token is provided. This works correctly, as we see the refresh token being renewed each time. We use that new refresh token when getting the next access token. 30 days after the permission is granted by our end user, the newly generated refresh token (which was generated 1 hour ago and never used) returns 'Invalid grant' when getting a new access token.

At first we thought it was an incident. But it persists month over month so we would like to know the cause and fix it.

These are our 'Offline Access Configuration' settings':

- Refresh token usage: One time

- Refresh tokens per user: 5

- The refresh token expiration is set to '30 days'

- But will expire if not used in [disabled]

- Update Access Token Claims [enabled]

Is there something wrong in our approach or settings? Do other devs experience the same issue?

Thanks!

[Sander_Feenstra]

Hello Mathijs,

I didn't claim changing the setting will help, just mentioned my settings.

I agree this must be a bug.

@Visma:  Please help us out and fix this please.

I connect from a background application but now my customers must re-consent for a new token every month. 

Best regards,

Sander Feenstra

[Mathijsdb]

Ah ok. In your case the behavior seems logical to me:

- Refresh token is not renewed at all because your setting is 'Re use'

- Expiration is set to '30 days'

- With every new access token, the refresh tokens remains equal to the 1st one

Because the access token is not renewed and expiration is set to '30 days', it makes sense in this case that after 30 days the refresh token is invalidated.

In my case, however, I set refresh token usage to 'One time'. With every new access token I also get a new refresh token (which should be valid for 30 days each in my opinion). After 30 days the newly received refresh token (which is created that same day) is invalidated within 1 hour, whereas I would expect that only the very first access token would be invalidated if it hadn't be used after 30 days. Other API's with oAuth I know all work that way.

@Visma?

[Sander_Feenstra]

Hi Matthijs,

I just encountered an "invalid_grant" error for unkown reasons at a customer.

It is indeed 30 days ago since the end user has retrieved the first access token.

These are our 'Offline Access Configuration' settings':

- Refresh token usage: Re use

- Refresh tokens per user: 5

- The refresh token expiration is set to '30 days'

- But will expire if not used in [disabled]

- Update Access Token Claims [enabled]

Best Regards,

Sander Feenstra

[Mathijsdb]

Hi Sander,

Thank you for your reply. I'm afraid that changing that setting doesn't solve the issue.

We had the setting 'Refresh token usage' at 'Re use' a few months ago. In that case, the refresh token stays always the same and will expire after the amount of days set in 'the refresh token expiration is set to', which we experienced at that time. Changing it to 'One time' resulted in a new refresh token with each access token renewal. In my opinion these  unique refresh tokens should be valid until used or when the expiration interval has passed. That is the behavior we see with other API's we connect with.

Currently, a new refresh token is created/provided each time but the refresh token expires after the very first refresh token was created / user gave consent in oAuth flow.

Is this a bug in Visma or am I missing something?

Thank you!

Mathijs

[Marten Voort]

Hi Mathijs, the refresh token lifetime is always based on initial codeflow. It determines how long you can use the app without having to log in again. One time use is only an additional layer of security. If every new refresh token would have its own expiration time, then you would effectively have an unlimited use in combination with the setting but will expire if not used in. 

You will find other examples of this practice, for example https://developer.okta.com/docs/guides/refresh-tokens/main/#:~:text=Note%3A%20When,user%20first%20au....

Let us know if this answers your question.

[Sander_Feenstra]

Hi Marten,

I understand but it's not quite ideal when connecting from a background application

and I haven't seen this behaviour in other API's.

But ok .. i set the expiration period to 180 days to minimize maintenance.

Thanks for your explanation.

Best regards,

Sander

[omelhus]

Hey Sander,

You should use a service application instead of a web-application for this use case. Access to your app will be granted through the app store, and you won't have this problem.

This will let you authenticate using client_credentials with a tenant id instead.

[adrianm]

> This will let you authenticate using client_credentials with a tenant id instead.

Only works if you can store the secret securely.

Otherwise you need to create one service application for each tenant.

[Sander_Feenstra]

Hi Adrian,

Thanks for you input. Unfortenately I can't keep a client secret secured, that why I use a native app.

Still think that the expiration period of a refresh token should be sliding since last use

instead compared to the first user consent.

Best regards,

Sander

[Marten Voort]

Thx for the update Sander!