mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 00:05:55 +03:00
[GH-ISSUE #1532] Authorization request to keymaster returns 403. #691
Labels
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#691
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @juliusdelta on GitHub (Aug 12, 2025).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1532
Look for similar bugs
This just started happening within the past 24 hours but I didn't see any other bugs like it :)
Description
403 Status code is returned from a Mercury request
Version
This is taken from the spotify-player repo for the version I am on.
How to reproduce
I'm just using spotify-player and sifting through the logs
Log
Host (what you are running
librespoton):Additional context
This issue is coming from the spotify-player program. Apologies if this isn't the right place but it seems the error is in the underlying PKCE Authentication flow which seems to be handled exclusively by Librespot.
I checked the Spotify api documentation to ensure that all those scopes being requested still exist and they seem to, however I'm no expert on how flaky they are.
I can provide more info if needed.
@juliusdelta commented on GitHub (Aug 12, 2025):
Related issue in spotify-player repo: https://github.com/aome510/spotify-player/issues/802
@photovoltex commented on GitHub (Aug 12, 2025):
Just a quick info, don't just blur out the
client_idas this is a public info that is required to debug the issue :). I found out through the other issues that the keymaster/officalclient_id(65b708073fc0480ea92a077233ca87bd) was used.@photovoltex commented on GitHub (Aug 12, 2025):
For now if you just need an
access_tokenyou can acquire one vialogin5(available on theSessioninstance). The token retrieved vialogin5has full scope access and is used internally by librespot.@Googolplexed0 commented on GitHub (Aug 13, 2025):
Experiencing the same exact same issue on a Python implementation of this repo. Creating a new set of credentials works but attempting to reuse them leads to a
MercuryClient.MercuryException: status: 403. I've looked across several other implementations (Python or otherwise) and they all are reporting similar issues.@michaelherger commented on GitHub (Aug 13, 2025):
Trying to use
login5in my case fails with some "Service unavailable" error:What other information can I provide to help investigating?
@michaelherger commented on GitHub (Aug 13, 2025):
Could someone please come up with an updated
examples/get_token.rsusinglogin5as a POC?@ltcmdrkeen commented on GitHub (Aug 13, 2025):
I did a PoC for integrating Login5 in librespot-java here: https://github.com/librespot-org/librespot-java/issues/1099
@photovoltex commented on GitHub (Aug 13, 2025):
@michaelherger, this (
github.com/photovoltex/librespot@59d0228a65) should already do the trick. But I didn't tested it and can only do that in around 12h@kingosticks commented on GitHub (Aug 13, 2025):
Is it worth investigating keymaster issues? What does it provide that login5 doesn't? I'm not keen unless there's a good reason.
If we are going to investigate them please provide the full log we explicitly ask for.
If we are not going to investigate we should deprecate keymaster.
@photovoltex commented on GitHub (Aug 13, 2025):
I looked a bit into it yesterday but didn't get too far. What I got from the quick investigation was that we use the ap for way more than the current official desktop client does. So I wouldn't be surprised if the keymaster isn't used anymore, but I couldn't find that out yet.
@urknall commented on GitHub (Aug 13, 2025):
Question from a beginner: [core] Add get_token_with_client_id() to get a token for a specific client ID:
get_token_with_client_id() and get_token() are still using keymaster?
so how can i get a token for a specific client ID with login5?
or does librespot provide another way to get a token with a client_id that i set as parameter via oauth maybe?
@photovoltex commented on GitHub (Aug 14, 2025):
In a previous comment I explain the changes necessary. One of them has a commit attached where you can see the changes in action.
@kingosticks commented on GitHub (Aug 14, 2025):
You can see the login5 code uses the client id from the session. There are also session methods to change the client id. Does that work? I can't remember. Go try it and tell us.
@photovoltex commented on GitHub (Aug 14, 2025):
Oh I missunderstood the question. I think I never tested it with other client_id's. But working with login5 is quite pin pointing, one wrong variable and it would report a generalized error, so I would be supprised if custom id's work.
@kingosticks commented on GitHub (Aug 14, 2025):
Me too. I thought it was locked down to Spotify's IDs but might be remembering wrong. Worth trying.
@urknall commented on GitHub (Aug 14, 2025):
i tried yesterday to manually set the client_id for the session, but i got an error. so i guess only "official" ids are supported.
@urknall commented on GitHub (Aug 14, 2025):
so right now that keymaster isn't working any more (probably depecreated) librespot is not able to get a token for a specific client, that the user has generated in the spotify dashboard?
@kingosticks commented on GitHub (Aug 14, 2025):
That's annoying if true. But you can just use their client ID for everything you do.... Given how hell-bent they are on screwing over legit devs I see no reason to play by their rules w.r.t this.
@urknall commented on GitHub (Aug 14, 2025):
you could be running in quota or rate limit problems without your own client_id when doing alot of web api requests.
this could be a way to get a token for your own client_id:
https://developer.spotify.com/documentation/web-api/tutorials/code-pkce-flow
@kingosticks commented on GitHub (Aug 14, 2025):
I don't understand what you are saying there, but yes, anyone is free to implement the regular Spotify OAuth flow themselves. We are not going to provide a wrapper around that.
Just remember that any client_id obtained from Spotify in the last few months is restricted in terms of endpoint access and quota.
I find it extremely doubtful you would hit quota limits using Spotify's special client ID. It's used by millions of people.
@urknall commented on GitHub (Aug 14, 2025):
i am only refering to the quota modes and rate limits in the spotify api documentation
@michaelherger commented on GitHub (Aug 14, 2025):
This likely has nothing to do with Librespot's interaction with Spotify's servers. Let's see what the next weeks will bring.
@urknall commented on GitHub (Aug 14, 2025):
after reading the quota and rate limit parts of the api documentation again, you both might be right.
when librespot is using official clients spotify client ids, that should not be a problem.
@kingosticks commented on GitHub (Aug 14, 2025):
The only thing left to do here is to deprecate keymaster or not. Ideally someone needs to have a quick play and decide if it really is entirely broken now (thanks Spotify) or did the usage requirements change. I don't think any of the Mercury endpoints get any love from Spotify so I'd imagine it's the former. Dumping the official client Mercury traffic might help answer this.
@roderickvd commented on GitHub (Aug 15, 2025):
Don’t we still need Mercury to get the track encryption keys? Until we’ve got a clean implementation of the HTTP endpoint for it.
@kingosticks commented on GitHub (Aug 15, 2025):
I only meant we could switch out
hm://keymaster/tokenwith login5 inTokenProvider. Am I forgetting why that would impact getting track encryption keys?Although, you raise a good point that working on using the HTTP endpoint for encryption keys would be a good thing to do.
@roderickvd commented on GitHub (Aug 15, 2025):
No, probably my mix-up.
@photovoltex commented on GitHub (Aug 15, 2025):
Isn't the HTTP encryption the
playplayendpoint, if so... that might be hard to get working as some related project that did revers it got taken down already, see es3n1n/re-unplayplay for example.@brzaz228 commented on GitHub (Aug 15, 2025):
It is not rate limits spotify is blocking some part of the process but not rate limits. I always use in realtime and have the script set have 5 seconds at least between downloads. Spotify also reached out to my personal email when rates got crazy and put a temp ban on my account.
@brzaz228 commented on GitHub (Aug 21, 2025):
Anyone make any progress or any failed attempts they want to update? I tried to alternatively route authentication to web each time for every song but it still didn't work
@kingosticks commented on GitHub (Aug 21, 2025):
Can you clarify why the login5 alternative isn't sufficient for you?
@SuisChan commented on GitHub (Sep 21, 2025):
Funny enough, yesterday I was disassembling one of the recent versions of the tv app, and it seems to still rely heavily on hermes and still use keymaster.
So far, I haven't seen any http/s stuff, and everything works over hm://?. From what I've seen, it's compiled using esdk (a newer version than what we see on the official development pages). I can't say for sure, since this was just a static analysis, but in any case, everything I've seen likely confirms my suspicions.
It even seems to be fetching audio files via hermes (not like the old protocol(channels)), but like it's sort of a wrapper around http via hermes connection.
Until I can do dynamic analysis, there's not much more to add
@SuisChan commented on GitHub (Sep 23, 2025):
Well, can confirm what I said before, it even fetches the audio URL (storage-resolve) via
hm://hwptp/v2/resolve, as well as the keys (still playplay)hm://hwptp/v1/content_encryption_key, and it looks likehm://keymaster/token/authenticated?is still working fine for them.@photovoltex commented on GitHub (Sep 25, 2025):
So probably our implementation isn't what Spotify expects and blocks it in response then? I saw a similar behaviors with login5 where it was quite picky what it accepted.
@SuisChan commented on GitHub (Sep 25, 2025):
I don't know what to think. Everything seems to be working, but the response shows an empty permissions list. Does that change anything? I have no idea.
One more thing: the client gets all the necessary info via the
hm://destination and doesn't seem to use http at all, but receives encrypted blobs, keys, events - basically, everything it needs. So why get a bearer token at all? That's the question.I might be wrong, but... I didn't intercept the http traffic (if there is any at all), only the encrypted stream, so who knows.
I'm not sure if this is worth investigating, but anyway
hexdump (keymaster & storage-resolve)
@brzaz228 commented on GitHub (Oct 21, 2025):
Anyone make any progress?