We will soon be releasing the ability for users to revoke account access for applications for which they have previously granted access. If you have written an app which uses the OAuth “Authorization Code” or “Implicit Grant” flows, you should make sure that you app is ready.

How this will affect your app

From August 9th, Spotify users will be able to visit https://www.spotify.com/account/ to revoke access for applications they have previously granted access.

If your application uses the “Authorization Code” or “Implicit Grant” flow, the user will be presented with your application’s name and description, along with a link to revoke access.

Approved Applications interface

If the user chooses to revoke access, any Authorization Code refresh_token you store on behalf of that user will be made invalid and you will be unable to use them to request additional access_tokens. If you use Implicit Grant, the scopes that the user previously allowed will be cleared and the user will be prompted to re-allow next time they use your application.

If a request is made to https://accounts.spotify.com/api/token with a revoked or expired refresh_token, your app will receive a 400 Bad Request response with the following payload:

HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

In order to continue using your application, the user will need to explicitly grant access by going through the Authorization Code flow again, as they did the first time they used your application.

What you should do

Ahead of this update, there are a few things you can do to ensure a good experience for your users:

  1. Update your application’s name and description The list of applications available for revocation will display your application’s name and description as specified in the developer portal’s “My Apps” section. Ensure that these represent an up-to-date, informative, and concise explanation of what your application does so that the user does not revoke your access simply because they did not recognise it.
  2. If you use Authorization Code flow, ensure your application can cope with an invalidated refresh_token. If the user instigates an action which requires a new access token, and access has been revoked, you should detect the denied refresh request (detailed above) and push the user into the initial oAuth flow.

    If your requests are automated and you receive an HTTP 400 error, you should halt automatic token refresh until the user has re-allowed access for your application.

  3. When access is revoked, clean up any cached information for that user. It is good practice to clean up any artifacts left over from a user who has finished interacting with your service or application. This can include any user-specific data you have cached along with any refresh_tokens or user-specific information within your app.