Refreshing tokens for PKCE-authorised users

[felix-hilden]

Hi,

OAuth2 specifications list PKCE as an extension to the standard. As you state in your documentation, the refresh token can only be used once. Why is this? I could not find such a recommendation, although the original spec did state that old refresh tokens may be revoked after a new one is issued. So why PKCE specifically, added security?

Granted, refresh tokens can be chained, and the tokens can be used for the full duration, even after consuming the refresh token. But having a single refresh token from which to spawn new tokens is quite practical. For my specific use case: performing automated tests against the Web API with e.g. Travis was possible thanks to generating a user token from the same refresh token over and over again. As PKCE was meant to be an improvement and replacement to the vanilla user authorisation, I'd like to see it being used exclusively, but this refreshing complicates things.

So, are you set on these semantics for PKCE? If so, are you planning on making the case for vanilla user authorisation stricter as well?

Many thanks,

Felix Hildén

[felix-hilden]

Additionally, how can one tell the difference between a PKCE token and an ordinary one? Refreshing with PKCE but using the refresh token of an ordinary token results in "400: Refresh token revoked", which is perhaps a bit misleading.

[quadule]

I am also curious about this. I'm developing a handheld Spotify remote and PKCE would allow me to release a firmware binary without shipping a client secret or requiring users to register their own application. This remote has to retrieve a new access token whenever it is powered on, so if it was ever unable to save the new refresh token due to network or battery issue, then the user would have to reauthenticate in a browser. PKCE seems like a good fit for this use case otherwise.

[laszloxgergely]

I think you are safe, you get a new refresh token each time you get the new access token, just save the new one along with the updated access token

[sudmike · Accepted solution]

You're right that the reason is added security.

The concept that with every refresh, both tokens get renewed and the old ones get invalidated is called 'refresh token rotation.' It prevents leaked refresh tokens from being used to generate access tokens. If an old, compromised refresh token were to be presented to the authorization server, it would notice and invalidate all tokens. Without refresh token rotation, it would not be possible to tell if a refresh token was leaked because both the rightful owner and attacker would be using the same refresh token to generate access tokens.

Refresh token rotation is especially useful with PKCE because PKCE supports browser-based authorization. Browsers can't securely store confidential data, so there is a higher risk that refresh tokens get leaked. Refresh token rotation is surely staying for PKCE. It might take a while for the vanilla authorization flow to adopt this concept though because it would break existing client implementations.

You can find more here https://auth0.com/docs/tokens/refresh-tokens/refresh-token-rotation.