Spotify

To improve security for our users, Spotify is planning to remove support for two ways of integrating with Spotify that have been replaced with more secure alternatives. This includes deprecating use of the implicit grant as well as removing support for unencrypted HTTP redirect URIs for your client.

All clients created from the 9th of April 2025 will have the new rules enforced automatically. Migration of existing clients to an acceptable state must be made by November 2025.

Here is a detailed guide with migration instructions.

PKCE for the authorization code grant introduced clients that can’t maintain a client secret (such as mobile apps or client side web applications) to a more secure way to integrate with Spotify. Current OAuth security best practices recommend against the use of the implicit grant, and it will shortly be removed.

Similarly, the widespread adoption of HTTPS across the internet has made it much easier to accept redirects over HTTPS instead of unencrypted HTTP. By moving traffic from HTTP to HTTPS, users of applications that integrate with Spotify will be better protected against attacks that intercept network traffic.

If you are using the implicit grant (sending response_type=token in your call to the authorization endpoint, or in the Android SDK using AuthorizationResponse.Type.TOKEN), then you will need to migrate to the authorization code grant.

If you are using a public client (one which cannot securely store a secret), you will be expected to use the PKCE extension. Confidential clients (ones which can store a secret) must use it.

Any redirect URI using HTTP will stop being supported, except loopback IP address literals such as http://127.0.0.1 for IPv4 and http://[::1] for IPv6. Any invalid redirect URIs will need to be changed. You can check them under your client’s ‘settings’ tab in the developer console.

Redirects using a custom scheme will still be supported, but we recommend developers to use HTTPS redirects where possible. For mobile applications, we recommend using Android App Links and iOS Universal Links where possible.

For example:

• http://www.example.com could be migrated to https://www.example.com
• http://localhost:3000 could be migrated to http://127.0.0.1:3000
• com.example://callback can still be used as before

Please make these checks for yourself. Comprehensive guidance will also be published via updates to the developer portal documentation.

Reach out to us on the developer community forum for feedback.