Spotify disabled username/password authentication

[kingosticks]

Fixed in the latest pre-release and forked version of gst-plugin-spotify. Read all of the README for details.

---

noting that Spotify disabled username/password authentication, which affects playback in 2024 on the https://github.com/mopidy/mopidy-spotify/tree/v5.0.0alpha branch,

users will see errors similiar to failed to start: Login failed with reason: Bad credentials

ERROR        spotifyaudiosrc audio/spotify/src/spotifyaudiosrc/imp.rs:328:gstspotify::spotifyaudiosrc::imp:<source> failed to start: Login failed with reason: Bad credentials
WARN                 basesrc gstbasesrc.c:3134:gst_base_src_loop:<source> error: Internal data stream error.
WARN                 basesrc gstbasesrc.c:3134:gst_base_src_loop:<source> error: streaming stopped, reason error (-5)
WARN                oggdemux gstoggdemux.c:4775:gst_ogg_demux_send_event:<oggdemux0> error: EOS before finding a chain
WARN                oggdemux gstoggdemux.c:2550:gst_ogg_demux_sink_event:<oggdemux0> EOS while trying to retrieve chain, seeking disabled

since this is an upstream issue with librespot-org/librespot#1308 a solution will be multi-tiered,

as always, ty @kingosticks, for your work on this

Originally posted by @troyxmccall in #110 (comment)

---

Thanks for adding this here also.

I would have thought things will continue to work for existing users because we support "cached credentials". Only the very first login actually uses your user and password. This does assume you are persisting the contents of Mopidy's data_dir where we store that blob. The default config location should ensure that's the case. I can replicate the problem if I move my cached creds elsewhere but it's still working otherwise.

Obtaining cached credentials (via a custom build of librespot, or similar) and moving them into this directory is a work-around.

Originally posted by @kingosticks in #110 (comment)

[kingosticks]

As already mentioned, this ultimately needs fixing in librespot. I have submitted a PR there to do that, hopefully it'll be merged when the maintainer has time. I'd appreciate review/feedback anyone has on that work but please don't hassle them there, everyone is busy and it's holiday season too - thanks Spotify! Once that (or something like it) is merged, we'll need to get support into gst-plugin-spotify. Depending what that support looks like, we may then also need to make changes to Mopidy-Spotify. As you can see, there are multiple projects involved so don't expect this to happen tomorrow. We could provide a custom build but I am reluctant because I'm not sure what gst-plugin-spotify will look like and I don't want to support another version of everything, even if it is short-term.

In the meantime, there is a workaround. You ultimately need to obtain a "cached credentials" file and drop this into your Mopidy-Spotify data directory (typically $HOME/.local/share/mopidy/spotify/credentials-cache/credentials.json or /var/lib/mopidy/spotify/credentials-cache/credentials.json). You can generate this file by running librespot and authenticating via "discovery" mode (AKA zeroconf).

1. Download rust and clone librespot.
2. From the librespot directory do cargo run --no-default-features -- --cache .
3. Use an official Spotify app (on the same network) to connect to the running librespot device using Spotify Connect
4. You'll then find a new credentials.json file in the librespot directory that looks something like

{"username":"fred","auth_type":1,"auth_data":"LOADOFSEEMINGLYRANDOMCHARACTERSBLAHBLAGBWOOTWOOt=="}

5. Copy this file into the appropriate Mopidy-Spotify directory as mentioned above.

If you cannot use Spotify Connect for whatever reason, you can alternatively get a credentials.json file using the new OAuth flow feature in the dev librespot branch: cargo run --no-default-features -- --cache . --enable-oauth.

[phuketbinaryt]

As already mentioned, this ultimately needs fixing in librespot. I have submitted a PR there to do that, hopefully it'll be merged when the maintainer has time. I'd appreciate review/feedback anyone has on that work but please don't hassle them there, everyone is busy and it's holiday season too - thanks Spotify! Once that (or something like it) is merged, we'll need to get support into gst-plugin-spotify. Depending what that support looks like, we may then also need to make changes to Mopidy-Spotify. As you can see, there are multiple projects involved so don't expect this to happen tomorrow. We could provide a custom build but I am reluctant because I'm not sure what gst-plugin-spotify will look like and I don't want to support another version of everything, even if it is short-term.

In the meantime, there is a workaround. You ultimately need to obtain a "cached credentials" file and drop this into your Mopidy-Spotify data directory (typically $HOME/.local/share/mopidy/spotify/credentials-cache/credentials.json or /var/lib/mopidy/spotify/credentials-cache/credentials.json). You can generate this file by running librespot and authenticating via "discovery" mode (AKA zeroconf).

1. Download rust and clone librespot.
2. From the librespot directory do cargo run --no-default-features -- --cache .
3. Use an official Spotify app (on the same network) to connect to the running librespot device using Spotify Connect
4. You'll then find a new credentials.json file in the librespot directory that looks something like

{"username":"fred","auth_type":1,"auth_data":"LOADOFSEEMINGLYRANDOMCHARACTERSBLAHBLAGBWOOTWOOt=="}

5. Copy this file into the appropriate Mopidy-Spotify directory as mentioned above.

If you cannot use Spotify Connect for whatever reason, you could clone my librespot branch instead and get your credentials.json via the new OAuth flow with cargo run --no-default-features -- --cache . --token ''.

I am getting this error when trying the last option:
Error parsing command line options: Unrecognized option: 'token'

[kingosticks]

Does 'token' appear as an option when you run with --help? If not, you're not using my fork. Also note the version should be '0.5.0-dev 27b2b59'.

cargo run --no-default-features -- -c . --help
...
librespot 0.5.0-dev 27b2b59 (Built on 2024-08-13, Build ID: 2q9wcmIs, Profile: debug)

An open source client library for Spotify, with support for Spotify Connect

https://github.com/librespot-org/librespot

Usage: target\debug\librespot.exe [<Options>]

Options:
...
    -k, --token TOKEN   Spotify access token to sign in with. Use empty string
                        to obtain token.

[phuketbinaryt]

Looks like cloning the git was giving me the wrong version indeed. Grabbed the zip and that sorted it all out. Thanks, working great now.

[pvincent4]

Thanks a lot for this quick fix.
Surprisingly it worked well yesterday adding manualy the credentials.json to my local folder... but today I get this error starting mopidy and its extensions :
pi mopidy[13812]: ERROR [SpotifyBackend-9] mopidy_spotify.web OAuth token refresh failed: invalid_grant Grant has been revoked.
pi mopidy[13812]: ERROR [SpotifyBackend-9] mopidy_spotify.web Failed to load Spotify user profile

I retried the procedure without success, a bit weird... Is somebody experiencing a similar issue?

PS : I guessed that values ​in mopidy.conf ​are not supposed to be removed (username, password, client_id, client_secret)

[kingosticks]

PS : I guessed that values ​in mopidy.conf ​are not supposed to be removed (username, password, client_id, client_secret)

The username and password fields won't actually be used once you've got a credentials.json in place. The client_id and client_secret might need updating if Spotify have reset your credentials? These are used by the mopidy_spotify.web module to access your account data. You can get new ones at https://mopidy.com/ext/spotify/

[geheim27]

Hi,
I tried the Spotify Connect workaround but unfortunately without success. Is there any log entry to verify the use of the credentials.json file by Mopidy?
Thanks

[kingosticks]

No. You could try the gstreamer logs: GST_DEBUG=3,*spotify*:6 mopidy.

[pvincent4]

The username and password fields won't actually be used once you've got a credentials.json in place. The client_id and client_secret might need updating if Spotify have reset your credentials? These are used by the mopidy_spotify.web module to access your account data. You can get new ones at https://mopidy.com/ext/spotify/

Well done, I reset the values ​​and that fixed the problem. Cheers

[geheim27]

Found my problem. Within mopidy.conf, I had the spotify login mail address but credentials.json contained the spotify username. Updated mopidy.conf and now its working.

[kingosticks]

Oh, excellent find. Thanks

[davestroker]

Thanks @kingosticks for your work. Unfortunatly i can not get it to work. I created the credentials.json on a windows machine and copied it to a linked folder on my server, where mopidy runs in a docker container.
I also did an update of the clientID and secret. It still gives me the "bad credentials" error. Is it even possible to create the credentials on another machine or does it need to be the machine were mopidy runs? I gues then its not possible to do it within the container!? Thanks a lot!!!

[kingosticks]

I would guess it might need to be the same OS (e.g. windows, mac, Linux), because the client ID used to generate the credentials file is OS-specific. But that's a guess.

[kingosticks]

As per my early comment with workarounds, if you can't use zeroconf on your server, use my forked version and do the oauth flow in headless mode cargo run --no-default-features -- --cache . --token "" --token-port 0.

[3052]

Spotify disabled username/password authentication

no, they didn't. you just have to specify user-agent

[kingosticks]

Great, thanks, that's super helpful.

[PureTryOut]

So steps for me to make this work were a combination of multiple things mentioned in this thread:

1. get a new valid credentials.json using LibreSpot when connecting to it from an official Spotify client
2. Update client_id and client_secret values from https://mopidy.com/ext/spotify/
3. Update the username field in mopidy.conf from my email address to the username mentioned in credentials.json. It seems to be an auto-generated username, there is no way I would be able to guess or know it

I hope this process can be simplified again at some point in the future because this was a bit of a hassle 😅

[powellc]

Hmm, has anyone else encountered Spotify flagging the mopidy connection as suspicious and resetting their password? The first time this happened it took a while and I didn't associate it with this method. But yesterday Spotify locked my account down within about 8 hours of setting this up. I'll try again, but am now discouraged.

[kingosticks]

It's happened to some users of librespot (and us by extension) because our software is still using their now deprecated username and password authentication flow. It's pretty stupid they're doing this (they gave us very little notice and didn't mention they'd also do this), but that's Spotify for you.... I've now got token based auth working but it relies on code that's not yet merged/released upstream. Hence it's slow. But it's coming and then we'll be able to remove the need for username and password entirely. Which is great for everyone.

Users that had working setups before should still be working because we've also been using "cached credentials", this login method is used in preference to user/pass auth. But I don't think it works for people with weird (Facebook) accounts where the username they log in with doesn't match their "real" Spotify username.

This entire mess is an effort by Spotify to increase account security and we're doing our best to catch up. Personally I have no idea why anyone would want to steal Spotify account credentials, presumably nobody is refusing their passwords in 2024... If you're worried about using your account with Mopidy-Spotify, all the software is available to view and you can build gst-plugin-spotify yourself from source. Spotify themselves are incapable of offering software like this for whatever internal reasons, we're incredibly lucky to have alternatives to their client. But all those alternative clients are based around unofficial software (librespot and its clones). I don't think Spotify intended to scare anyone away from using librespot. After all, they did proactively reach out to the project with a heads-up about the upcoming change. I think they just make a lot of mistakes.

[kingosticks]

I should also add, cached credentials will also not work if you've managed to configure Mopidy incorrectly. There is currently zero checking and logging of cached credentials usage so it's not obvious when this is happening.

[powellc]

Thanks for the quick reply @kingosticks ... my discouragement was not fear of using my account with Mopidy-Spotify, but bothering to keep this clunker running with mopidy at all. Also, I think you're right ... I definitely have an OG "weird" Facebook account ID for my username, so that very well may be part of the calculus here.

Thanks again for the help!

[The-Judge]

I'm also looking forward to this clear, non-username/password auth ... Phonieboxes are down now for over a year for me ...
I also have to add that this non-working auth mechanism comes with another unpleasant side-effect: The Account used for the Phoniebox gets locked each time the box boots up. Most certainly because the unsuccessfully auth is treated like some Brute-Force attack and account security kicks in.

[kingosticks]

I understand the frustration, but the auth problem is relatively recent. The issues in the project over the last few years have been due to all kinds of things. And that's inevitable when Spotify leaves us to reverse engineer everything, and changes stuff over time. I hope that fully moving to librespot, and me working on both (if only temporarily, I cannot keep this up) will help get us back on track. I think PhonieBox are also in a period of change so it's unfortunate timing. I did look at helping a while back but it seemed most of the focus was on their new, non-spotify flavour. Can look again when this is working and stable. I have a potential PhonieBox user of my own to motivate me.

[The-Judge]

Just brainstorming here: I installed "Volumio" yesterday, which also is a Debian based MediaBox, but with a different focus than the Phonieboxes have.
Anyways: They claim to have a:

[...] new, totally rewritten (literally), perfectly working plugin for Spotify

I gave it a try and yes: You have to auth using Spotify's Standard-Auth mecha and don't have to create some ClientID and Secret manually; nor does it save the username or password.
Also, It's working like a charm!

Spotify support has to be downloaded as a Plugin from here. From the filename, it looks "familiar": vollibrespot

Maybe that's something that also is implementable in Phoniebox?

[kingosticks]

That's cool. Although I have my own personal opinions on the value of fragmenting the eco system with yet another rewrite but there you go. Having zero compatibility/technIcal-debt is very nice to have.

We should also be able to get rid of our client ID and secrets too also. That is a hangover from long ago, before Spotify support the oauth PKCE flow. See... isn't it nice to rewrite from scratch. I'm not actually jealous, that's a huge amount of effort.

[alanmilinovic]

And what about spotify making login connection suspicions? I had to reset my password couple of times because spotify thinks we are doing something fishy. :)

[kingosticks]

That's cool. Although I have my own personal opinions on the value of fragmenting the eco system with yet another rewrite but there you go. Having zero compatibility/technIcal-debt is very nice to have.

We should also be able to get rid of our client ID and secrets too also. That is a hangover from long ago, before Spotify support the oauth PKCE flow. See... isn't it nice to rewrite from scratch. I'm not actually jealous, that's a huge amount of effort.

Ohhh, it's based on librespot-go. I take it all back, the developer is that has been around and helping for years. That's great news.

[kingosticks]

@alanmilinovic as I said earlier:

because our software is still using their now deprecated username and password authentication flow

The new version has that fixed. It'll be released soon.

[alanmilinovic]

@alanmilinovic as I said earlier:

because our software is still using their now deprecated username and password authentication flow

The new version has that fixed. It'll be released soon.

Very nice, happy to test it.

[kingosticks]

Please put this in a separate issue. It does not belong here.

[The-Judge]

I am very sorry to ask how to do all of this again, but I consider myself not being a complete IT-moron but yet, I can't get this to work, unfortunately.
I installed the Phoniebox v2 just as the docs say. No visible error experienced.

Since the librespot compile was missing these components, I then installed:

• cmake
• libclang-dev

Next, I Installed Rust and Cargo (defaults applied): curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh).

Using librespot commit 3781a089a69ce9883a299dfd191d90c9a5348819 (which has the fix from #1309), I then executed the non-spotify-connect variant: cargo run --no-default-features -- --cache . --enable-oauth and successfully created the credentials.json file.
Next, I stopped the cargo process (ctrl+c), created the path $HOME/.local/share/mopidy/spotify/credentials-cache and copied credentials.json there.

Finally, I restarted the Pi.
I heard the Phoniebox-chime and navigated to the Web-UI. Clicking on "Spotify", Iris asks me for that Client's Identifier, which I set and I'm lead to the Iris UI then.

Navigating to Settings > Spotify looks as if I'm not logged in yet and using the search causes JSON errors:

What am I missing?
I don't even know which logs to provide ...

Doesn't that new librespot version need to be installed in addition to a good credentials.json file or something?

[troyxmccall]

@The-Judge happy to help you debug this if you move it over to: https://github.com/mopidy/mopidy-spotify/discussions/categories/q-a so we don't clog up this issue

[kingosticks]

Fixed in Mopidy-Spotify v5.0.0a3 and gst-plugin-spotify_0.14.0~alpha.1-1.

[PureTryOut]

So how do you get this access token? Is that the auth_data property in credentials.json?
Although it complained about not having access-token (I didn't set it in the config because I don't yet understand where to get it from) an updated credentials.json seems to have worked 🤷 Note that I'm not yet using your version of gst-plugin-spotify, is that what I'm missing?

Traceback (most recent call last):
  File "/usr/lib/python3.12/site-packages/mopidy/audio/actor.py", line 577, in _on_source_setup
    self._source_setup_callback(source)
  File "/usr/lib/python3.12/site-packages/mopidy_spotify/backend.py", line 50, in on_source_setup
    source.set_property("access-token", self.backend._web_client.token())
TypeError: object of type `GstSpotifyAudioSrc' does not have property `access-token'

[kingosticks]

Note that I'm not yet using your version of gst-plugin-spotify, is that what I'm missing?

Bingo.

Although it complained about not having access-token (I didn't set it in the config because I don't yet understand where to get it from

You just need to setup everything as the readme states. If it required extra steps, I would provide them.

[PureTryOut]

Ah ok, thanks. I'll wait for a proper release of gst-plugin-spotify then 👍

[kingosticks]

It's currently blocked waiting for the librespot v0.5 release. Which is only blocked by one PR - it's close!

[chiguire]

Thank you for providing the workaround! We did have to stop using the module for the moment, even with the workaround, because Spotify would disable the credentials by the next day, and it just became really annoying to reset the password each time we used the module. And until now we also had to provide the username and password because that's what the module used for searching.

[kingosticks]

The workaround is no longer necessary. The latest pre-release is fixed. Follow the instructions in the readme, including deleting any credentials.json file you may have been using.

Username and password has only been required for playback for some time. We stopped using them for search approx 9 years ago. Now they're not required at all and I suggest removing them from your config.

[kingosticks]

It's currently blocked waiting for the librespot v0.5 release. Which is only blocked by one PR - it's close!

@PureTryOut In case you didn't already see, librespot v0.5 has been released, and latest gst-plugins-rs now supports it.

[PureTryOut]

Latest gst-plugins-rs being 0.13.2? That's been released 4 weeks ago already, are you sure that uses the last librespot?

[kingosticks]

No, latest code in their repo. They can't backport it to 0.13.x because it requires a newer rust version. I'm not sure when 0.14.0 is due for actual release, sorry.

[PureTryOut]

Ouch ok, a bit more waiting then!