Spotify is a very popular audio streaming service, one that long has courted app developers with SDKs and API endpoints. However, their developer offerings keep changing, and their SDKs and documentation do not always keep pace.
One aspect of their setup is the “redirect URI”. Ostensibly, this is for OAuth, but they require it even in places where OAuth is not being used. Of note, they claim that the redirect URI needs to exist and match in three places:
-
In the app details that you post to their developer console
-
In the value that you pass in various API calls to their SDKs
-
For Android apps, in the manifest entry for some activity that will react to SDK call responses, in the form of an
<intent-filter>
In February 2025, they posted that they were tightening up the rules surrounding redirect URI values, especially their schemes:
Any redirect URI using HTTP will stop being supported, except loopback IP address literals such as
http://127.0.0.1for IPv4 andhttp://[::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.
They specifically cite that “com.example://callback can still be used as before”.
However, this does not seem to be the case.
I was experimenting with Spotify integration. Using their latest
Android SDK, I was unable to authenticate by any means, including both
their auth-lib
(what I wanted) and
their “built-in auth flow”.
When I eventually tried logging in through a Web browser, using
AuthorizationClient.openLoginInBrowser(), the browser gave me a plain-text
error screen saying that I had an “insecure redirect URI”.
While “insecure redirect URI” did not come up much in searches, the use of “insecure” echoed back to that February blog post. I was using a custom scheme at the time, and I wondered if their blog post was mistaken about Spotify’s support for custom schemes.
As soon as I switched from a custom scheme to https, everything started working.
Note that for auth-lib, at least for the Spotify app-based authentication
(AuthorizationClient.openLoginActivity()), you do not need the <intent-filter>,
let alone have it configured for an App Link. My guess is that this will be
important if you might wind up with authentication via a browser, such as because
the Spotify app is not installed or is unavailable for some reason. In my
case, simply using https for the redirect URI in the developer console and
in my Kotlin code was sufficient.
So, if you are having Spotify integration authentication problems, and you are
using a custom scheme, try switching to https — you might have
better luck.
