After migrating to expiring access tokens, do I need to write a scheduled task to continuously obtain a valid access token if I have multiple services that need to use it?

Authentication & Access
1

According to the documentation, I noticed the following points:

· The access token expires every 1 hour, and multiple valid tokens can exist at the same time (for example, generated multiple times within that hour using the refresh token).
· The refresh token may change after each refresh, returning a new one while the old one becomes invalid.

I currently have multiple services (such as some scheduled tasks and batch data processing for merchants). For non-expiring access tokens, it’s simple: the service at the very front of the OAuth flow can just send the access token and shop information to each service.

But if I migrate to expiring access tokens, based on the two points mentioned above, only one place should be allowed to refresh the access token, because each refresh will change the refresh token and invalidate the old one. So individual services cannot refresh on their own. Also, since each access token expires in just 1 hour, I might need to write a scheduled task to refresh the access tokens for all merchants at intervals shorter than 1 hour, to ensure all my backend services can run properly.

Is my understanding correct?

I’m also wondering: if I have 10,000 merchants and I do a full refresh of all access tokens every 20 minutes, will I hit rate limits? Is such behavior allowed?

And if during this process my database service encounters an exception that causes the new refresh token not to be recorded, then my merchants would have to reinstall my app, right? I feel like this seems very fragile.

2

This is a great question. I’ll tell you that I did. The reason being is because, just like you’re saying, the token expires every hour. If a user makes a request after that hour I have to get a 401, then kick off the rotation process. With the scheduled task, I recognize when the access token is getting close to expiration, rotate them, then the user doesn’t have a “slow” experience due to the annoying rotation process needed to take place AFTER the request was made just to turn around and make a new request.