-
Notifications
You must be signed in to change notification settings - Fork 654
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify Authentication documentation #1086
Comments
Yes, I am afraid this is true for most of the documentation.
Unless someone is working on getting OAuth flows working (I think there was an effort by Feel free to update any docs you find! |
So you confirm that none of the 4 officials OAuth flows are currently supported? I may be interested implementing the Authorization code flow as that will allow me to share the token between That or I re-implement the catalog search using |
I cannot say with certainty as I have never tried myself. I have some doubts whether tokens gotten through OAuth will be valid to authenticate on Mercury. They might be. But they (web vs. Mercury) may also well be different contexts. I remember someone theorising that one certain OAuth scope might also work on Mercury. I can't remember where I read that... probably also at the Java port or maybe on Gitter. |
Hi, I've been looking recently into registering the client into my account using an access token, I would like to share what I discovered in case it's interesting to someone, this project has helped me a lot https://github.com/TimotheeGerber/spotify-connect. It seems to be posible to authenticate a speaker using an api token as long as it has the "streaming" scope. I have tried to modify the tool to force it to use the same token I'm using with the web SDK (an access token obtained through oauth) and when using the tool auth method default-token everything seems to work.
Auth method access-token exposed by the library doesn't seem to work with librespot. Tested agains librespot v0.4.2. Regards! |
Maybe I misunderstand what you are saying. Is it that you have one token, which includes the "streaming" scope (and presumably a load others also) and that one token can be used with the Web API and librespot? Assuming that's the right understanding, where did you get that token from? |
The same token I use when my web application relays on the Web Playback SDK, I only use librespot for the electron version. Yes I have another scopes on the token, but I think based on the tool code that only the "streaming" one is required. I think it's enough for Librespot to authenticate to the Spotify account and swap to a reusable credentials. |
As a personal opinion, I think that having the https://github.com/TimotheeGerber/spotify-connect functionalities exposed in someway by librespot itself could be awesome, this way you can use same binary to authenticate the speaker through command line, and even, exposing a manual authentication page should be easy to build. I'm telling all this without knowing if authenticating with the access token have some side effect, but for me doesn't seem to be the case. |
Ahh, excellent! I didn't realise you could legitimately get the streaming scope as I have never used the Web Playback SDK. And your modification was to change the client ID to your own? I wonder if you do need some extra scopes for some parts of librespot to work. |
I changed the whole line that call get_token by a literal string containing a token generated by my app backend. I tested it with and without this modification and both times it worked. And without the modification the token is just generated with the streaming scope.
I think that not, because I think that the token that you are providing is not used by librespot anymore after the authentication, it generate it's own credentials and from those it is able to generate new tokens (using other client ids, so I think the client id you generated the token with is also not used at all). |
OK, with you now. Sorry, it's been a while. Yes and you're right, librespot does it's own fresh login afrer decrypting the blob sent by that spotify-connect tool. It does seem like there are some useful alt login methods that could be documented. i.e. from username and Web API "streaming" token. That could be a useful method to have if you want to share the same token. It looks like supporting "accesstoken" login in librespot might just be a case of fixing handle_add_user to check the "tokenType" response param and skipping all the decryption and just return |
@GiviMAD : thanks a lot! I manually created a I faced an issue when trying to request lyrics from |
There is a request for allowing the Device Authorization Grant flow on the Spotify forum - it is very useful for embedded usecases like a remote control. |
Oauth is implemented and documented now. |
The Authentication doc seems a bit outdated.
I think it would be good to list each method from Spotify Authorization's documentation and explain for each if they are supported (or planned to be).
rspotify
does exactly that which I found very helpful.The text was updated successfully, but these errors were encountered: