Lifetime of a refresh token

[0xNF]

For applications that have received a refresh token through the authorization_code flow, there's no documentation on how long a refresh token lasts. There's no obvious expiration date, and I'm pretty sure that the text a new refresh token may also be returned was added relatively recently.

Is there any published guidance on when to expect a new refresh token to be returned?

[bih]

Hey @0xNF,

The refresh_token logic hasn't changed, and we would share such a change with third-party developers if it was a breaking change. Also, I can't seem to find a new refresh token may also be returned in any of our docs, but if you give more information I can take a deeper look into this.

To clarify, you should only receive one refresh_token per authorization. If the user re-authorizes, it may return a new refresh_token. It doesn't matter which one you use at this point, because they are all indefinite until a user specifically de-authorizes your application in their Apps Settings, in which case they will all expire.

Hope this helps! I'm closing this as it isn't an issue. Feel free to re-open if this changes 👍

[0xNF]

Thanks for the response, sorry I didn't link the corresponding documentation page originally, my bad.
https://developer.spotify.com/documentation/general/guides/authorization-guide/

I might be misinterpreting "A new refresh token might be returned too." In that case, does that imply that if a user accesses the token endpoint again with grant_type=authorization_code that an existing refresh token might be returned to them?

[bih]

Hey @0xNF,

Ah okay, yes it is correct in that it may return a different refresh tokens. Which one you store, as mentioned, is irrelevant as long as the user has not revoked your application. If they have, of course, you'll need to get a new refresh token.

To answer your question, I have tried multiple authorizations (with the same user/application/scopes) and was given a new refresh_token every time. I would recommend just storing the latest refresh_token in your database.

To make it even clearer, I'll consult the team who works on Web API to clarify this to make sure others are not misinterpreting it 👍

[0xNF]

I'd actually like to take the time to thank you guys for your authorization guide.

It's the most clearly explained OAuth guide I've ever seen, and I routinely consult it for applications that aren't even remotely related to Spotify.

[ErikAGriffin]

To clarify, you should only receive one refresh_token per authorization. If the user re-authorizes, it may return a new refresh_token. It doesn't matter which one you use at this point, because they are all indefinite until a user specifically de-authorizes your application in their Apps Settings, in which case they will all expire.

@bih I'm still a little confused by the behavior of the API and want to make sure I'm not missing something.

A user may authorize a login through my application on one of any number of devices. When an authorization occurs, the new access and refresh token are stored.

Now when an existing access token returns a 401 and I request a new access token using the refresh token, the response includes an access token but no further refresh token.

So it seems there is no way to manage authorization of a user for more than two hors? That is we have the force the user to make another GET request to the authorization endpoint, something we cannot do on their behalf.

When describing the use of a refresh token this is where the docs say a new refresh token might be returned but give no specifics as to when that does or does not occur: [emphasis mine]

Are there any guidelines on how to ensure a new refresh token will be returned, so that the user's session can not be interrupted?

[jscholes]

@ErikAGriffin The practical expectation is that once a user has been authorized, and you've stored the initial refresh token, that refresh token can be used until the user de-orthorizes your app, deletes their account, whatever. Once an access token expires, you can request a new one, and for completeness the documentation does note that a new refresh token can also be returned. But again, the practical expectation is that this won't happen and may not be necessary. So you should handle it if it does happen, but otherwise you should just kepe using the old refresh token and new access token.

Given the above pattern, I don't understand your assertion that your users cannot have several uninterrupted sessions. If you have one app running on several devices, you shouldn't be sharing access or refresh tokens between those devices anyway. Each device (each app instance) should have it's own access token and refresh token pair, and you can just keep using the refresh token indefinitely to ensure an uninterrupted session on one device.

[ErikAGriffin]

@jscholes Ahh thank you so much for the clarification. I was under the impression refresh tokens were good for only one new access code, not that they could be used repeatedly to renew a user's session. Thanks for your prompt reply!

[0xNF]

I was under the impression refresh tokens were good for only one new access code, not that they could be used repeatedly to renew a user's session.

I recall being under the exact same impression when learning OAuth for the first time. It's not the most intuitive spec in the world, for sure.

[DrFizzles]

Sorry to bring up kind of an old issue, but I am having a problem possibly related to this.

I am setting up authorization as outlined here.

I get back the access token and refresh token and everything. However I noticed that when using the refresh token to get a new access token, the resulting token information doesn't come with a new refresh token.

I'd assume this is intentional, but that would mean that my authorization only lasts a max of 2 hours (1 hour for the initial token and 1 hour for the refreshed token).

When looking at what is supposed to be returned by the refresh_token call, it shows that it doesn't come with another refresh token.

Is there something I'm missing here?

[jscholes]

Assume that a refresh token will last until the user revokes auth for your app, not just 1 hour.

[DrFizzles]

So the refresh token can be used an indefinite number of times to get a new access token?

I'm fairly new to OAuth and refresh tokens in general, so I'm sorry if this seems like general knowledge.

[0xNF]

Yep, refresh tokens have an infinite duration and the same refresh token is used to get an infinite number of new access tokens. Each time the access token expires, you use the old refresh token to get a new access token. Always the same refresh token - unless, like jscholes says, the user revokes it.