How to refresh tokens gracefully

[promontis]

Not really about IdSrv3 but I hope you could still provide some guidance.

When refreshing the access token (using a refresh token), what should trigger such an action? Should I either:
A) store a timestamp before requesting the token. Then add the "expires_in" to that timestamp and check before every API call if the access token is still valid (not expired). Otherwise, refresh the token, and make the API call.
B) just do the API call (do not take into account if the access token is still valid). When the access token is not valid (expired), handle the unauthorized status, refresh the token, and make the API call again

If A is the way to go, should I store the timestamp before or after requesting the token? I can imagine if I'd store it after the request, the actual expiration moment could be slightly too late (because of the period between sending the response from IdSrv and receiving that response in the client + calculating the expiration time.

[leastprivilege]

I typically recommend a) - when you receive the token, use the expires_in to calculate the expiration time - and refresh the token when the time has come (maybe a bit earlier ;)

[promontis]

Ok Thanks!

[promontis]

Just a small question on the same topic to see if I'm correct. Answer might also serve other people.

I was getting an invalid grant message from the token endpoint when I ask for a new token using a refresh token grant. I didn't understand what was happening. However, after looking at the source code I noticed that the refresh token store is an in-memory store. Since I was stopping and starting my identity server with every test run, I guess this is why I am getting the invalid grant message.

I think I should start using the Thinktecture.IdentityServer.v3.EntityFramework package to persist those refresh tokens in a database, right?

PS: Perhaps we should change that invalid grant message to a more descriptive one as this was a little confusing for me. Something like "Refresh token not found in store (Perhaps you are using the in-memory store. If so, you might want to persist your refresh tokens)" Or perhaps write some more guidance in the wiki?

[leastprivilege]

Yes you need to persist refresh tokens for "real" scenarios. We already log at startup time that we are falling back to in-memory if no persistence store is configured.

[promontis]

Ok cool! I think people might overlook the log lines at startup. I think adding a small note on the wiki page on refresh token could help people to realize they are using an in-memory store. Anyhow... closing this issue again