nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Question about offline refresh token expiration and rotation behavior

ogawatomo

I'm implementing a server-to-server batch integration using the Dropbox API v2 with OAuth 2.0. I'm using token_access_type=offline to obtain a refresh token, and calling grant_type=refresh_token before each batch run to get a fresh access token.

I have two questions that I couldn't find clearly documented:

1. Refresh token expiration
Does the offline refresh token ever expire on its own (aside from explicit revocation by the user or app)? If so, what is the typical validity period? Also, is there a specific error code or response field (e.g., invalid_grant) that reliably indicates the refresh token itself has expired or been revoked, as opposed to a transient error?

2. Refresh token rotation
When calling /oauth2/token with grant_type=refresh_token, does the response ever include a new refresh_token value? If rotation can occur, is the previously issued refresh token invalidated at that point?

We're currently storing the refresh token as an environment variable, and depending on the answers above, we may need to move to a database or AWS Secrets Manager with an update mechanism. Any clarification would be greatly appreciated.

Find more posts tagged with

API

Comments

Здравко

Hi @ogawatomo,

Refresh token is permanent and it doesn't expire on its own. So:

1 - No.

2 - No.

Good luck. 😉

iNeil

Hi @ogawatomo,

Здравко is correct that refresh tokens do not expire automatically and can be used repeatedly. When you use a refresh token to retrieve a new short-lived access token by calling the oauth2/token endpoint with grant_type=refresh_token, the response does not provide or include a new refresh_token.

For more information about using refresh tokens to obtain new short-lived access tokens, please review the following documentation:

Using OAuth 2.0 with offline access - Example Workflow

If you have any additional questions, please let us know.

ogawatomo

Hi @iNeil , @Здравко,

Thanks for the quick and clear answers — this is exactly what we needed. We'll keep storing the refresh token as-is with no rotation/expiry handling, and just watch for invalid_grant in case of manual revocation. Appreciate the doc link too!