Todo: Reverse engineer new Facebook login flow.

[devgianlu]

The Facebook login flow described in the docs is outdated. This is the result of visiting that endpoint:

[sashahilton00]

New URL client requests in browser is: https://login2.spotify.com/login-facebook-sso/login?token=Ci0IARIpCInV-ojvLBIgjCK8h8zIv_ioJFP8FD2Nj1GpNARTIqF8Pb6WVtMLTJ0SILGE_PXbS48xP3YXkgTrY4ZfeGsq77r-F9LYsCIDiAiB
will take some further digging to work out exactly how it works, but my guess is that it opens up a websockets connection, requests a login token, then the server notifies the client once that token has an access token associated to it from the facebook auth callback. Anyone is welcome to poke around inside the Spotify client to work out what's going on, I will eventually get around to it, but it's low on the priorities list as i don't use facebook.

[sashahilton00]

Also, this login flow seems to be exclusive to the desktop app. Mobile app uses a different flow.

[sashahilton00]

Ok, so here's how the auth flow works:

1. Spotify client makesa a GET request to: https://login2.spotify.com/v1/config that returns the following:

{
	"login_url": "https://login2.spotify.com/login-facebook-sso/login?token=Ci0IARIpCIK_ocnvLBIgVelyXIR_MA...ik_wCYbJBq9",
	"signup_url": "https://login2.spotify.com/login-facebook-sso/signup?token=Ci0IARIpCIK_ocnvLBIgVelyXIR_MA...ik_wCYbJBq9",
	"cancel_url": "https://login2.spotify.com/v1/cancel?token=Ci0IARIpCIK_ocnvLBIgVelyXIR_MA...ik_wCYbJBq9",
	"credentials_url": "https://login2.spotify.com/v1/credentials?token=Ci0IARIpCIK_ocnvLBIgVelyXIR_MA...ik_wCYbJBq9"
}

2. A browser window is then opened to the login_url, which redirects to the Facebook login page.
3. The Spotify client begins HTTP polling the credentials_url, which returns 202 Accepted responses whilst awaiting authentication. Once authenticated, the credentials_url returns a 200 OK response, with the following payload:

{
	"credentials": {
		"username": "sashahilton00",
		"auth_type": 1,
		"encoded_auth_blob": "QVFCcFl...RtaHc="
	},
	"error": null
}

where the encoded_auth_blob is the base64 encoded auth blob.

This behaviour shouldn't be particularly hard to implement in librespot. There are no API keys/special headers involved with the endpoint at the time of writing, so librespot could fairly easily adopt a --fb-login flag that retrieved the auth URL, printed it to console, then polled it until the auth was complete. I'd suggest a 5 minute cutoff for polling so as not to leave one instance of librespot endlessly polling if someone starts it and then doesn't authenticate, rather just panic if no auth received by then.

I may get around to implementing this, but as mentioned previously, I don't use it, so it could be a while.

[devgianlu]

Works nicely (librespot-org/librespot-java#16)! I'll leave up to you when to close this issue.

[sashahilton00]

Cheers, we'll leave this open for now. Currently Facebook auth isn't actually implemented in librespot, but it comes of the category of useful to have, hence will leave it here until it gets implemented at some point.

[medwards]

Heads up: Sasha's analysis in #244 (comment) is no longer accurate, all of these URLs are now redirects to a deprecation notice page. (see hrkfdn/ncspot#310 )

[sashahilton00]

If I get some time I'll take a look at the new process. I wish they'd stop fixing stuff that wasn't broken...

[medwards]

I wanted to try to reproduce the reverse engineering you did for the old version but I wasn't able to. I was trying to listen to http/https traffic to at least see the URLs but wasn't able to see anything. Do you have any tips on how to do it?

[medwards]

pinging @sashahilton00 since you figured this out last time and it looks like discussions don't notify you of discussion updates.

[sashahilton00]

So the Facebook login flow now looks like this (for the desktop client):

1. The user is redirected to the following URL by the client:

https://accounts.spotify.com/login?continue=https%3A%2F%2Faccounts.spotify.com%2Fauthorize%3Fclient_id%3D65b708073fc0480ea92a077233ca87bd%26response_type%3Dcode%26redirect_uri%3Dhttp%253A%252F%252F127.0.0.1%253A4381%252Flogin%26scope%3Dapp-remote-control%252Cplaylist-modify%252Cplaylist-modify-private%252Cplaylist-modify-public%252Cplaylist-read%252Cplaylist-read-collaborative%252Cplaylist-read-private%252Cstreaming%252Cugc-image-upload%252Cuser-follow-modify%252Cuser-follow-read%252Cuser-library-modify%252Cuser-library-read%252Cuser-modify%252Cuser-modify-playback-state%252Cuser-modify-private%252Cuser-personalized%252Cuser-read-birthdate%252Cuser-read-currently-playing%252Cuser-read-email%252Cuser-read-play-history%252Cuser-read-playback-position%252Cuser-read-playback-state%252Cuser-read-private%252Cuser-read-recently-played%252Cuser-top-read%26code_challenge%3D9svEXKLALlMq...Wp4c9vjaIlIZfI%26code_challenge_method%3DS256&method=facebook&utm_source=spotify&utm_medium=desktop-win32&utm_campaign=organic

This results in being redirected to Facebook. Note the 127.0.0.1:4381 in the redirect URI. What happens behind the scenes is that the Spotify app spins up a server on port 4381 before sending the user to that URI.

2. The user auths with Facebook, at which point Facebook redirects the user to the URI:

https://accounts.spotify.com/authorize?client_id=65b708073fc0480ea92a077233ca87bd&response_type=code&redirect_uri=http%3A%2F%2F127.0.0.1%3A4381%2Flogin&scope=app-remote-control%2Cplaylist-modify%2Cplaylist-modify-private%2Cplaylist-modify-public%2Cplaylist-read%2Cplaylist-read-collaborative%2Cplaylist-read-private%2Cstreaming%2Cugc-image-upload%2Cuser-follow-modify%2Cuser-follow-read%2Cuser-library-modify%2Cuser-library-read%2Cuser-modify%2Cuser-modify-playback-state%2Cuser-modify-private%2Cuser-personalized%2Cuser-read-birthdate%2Cuser-read-currently-playing%2Cuser-read-email%2Cuser-read-play-history%2Cuser-read-playback-position%2Cuser-read-playback-state%2Cuser-read-private%2Cuser-read-recently-played%2Cuser-top-read&code_challenge=XXX&code_challenge_method=S256&utm_campaign=organic&utm_medium=desktop-win32&utm_source=spotify

This then presents a page where the user can click a button to 'Continue to app'.

3. Upon clicking Continue to app, the webpage makes a request behind the scenes to https://accounts.spotify.com/authorize/accept, sending the code_challenge, code_challenge_method (for which the value is S256) and csrf_token variables, along with a few others such as scope. If successful, the server responds with a 302 that points to the redirect_uri mentioned previously, http://127.0.0.1:4381/login?code=XXX, the server spun up by the Spotify app.

4. The Spotify app then makes a request to https://accounts.spotify.com/api/token, passing the parameters grant_type, client_id, redirect_uri, code_verifier and code, where the latter is the authorisation code. I haven't investigated the code_verifier parameter, but it appears to be tied in to the aforementioned code_challenge and code_challenge_method. If the data passed is deemed valid, Spotify servers respond with a json response with the usual OAuth2 type response:

{
	"access_token": "xxx",
	"token_type": "Bearer",
	"expires_in": 3600,
	"refresh_token": "xxx",
	"scope": "playlist-modify ugc-image-upload user-follow-read user-read-email user-read-private app-remote-control streaming user-follow-modify user-modify-playback-state user-library-modify playlist-modify-public playlist-read user-read-birthdate user-top-read playlist-read-private playlist-read-collaborative user-modify-private playlist-modify-private user-modify user-library-read user-personalized user-read-play-history user-read-playback-state user-read-currently-playing user-read-recently-played user-read-playback-position"
}

5. If a successful auth occurs, the response from the server spun up by Spotify on port 4381 to the request initialted in step 3 should be a 302 redirect to https://open.spotify.com/desktop/auth/success, or otherwise a 302 redirect to https://open.spotify.com/desktop/auth/error.

If the Facebook auth doesn't occur within about 15 minutes, the 4381 server is automatically shut down.

UPDATE: Looks like the code verifier stuff is standard as well: https://www.oauth.com/oauth2-servers/pkce/authorization-request/

[sashahilton00]

@medwards not sure if it auto-notifies, so pinging directly.

[michaelherger]

I haven't investigated the code_verifier parameter, but it appears to be tied in to the aforementioned code_challenge and code_challenge_method.

This is part of the PKCE flow (see https://tools.ietf.org/html/rfc7636#section-1.1): the code_verifier is some random value you define in the client before initiating the auth flow. You then transform it using the code_challenge_method and send the result of this in the call to authorize as the code_challenge. Once the user gets back to the application, you'd receive a code. You'll have to call api/token to exchange the code with a token. In this call you don't send the transformed value again, but this time you send the "raw" code_verifier. As the endpoint remembers the method you chose they will verify that if they transform code_verifier using the code_challenge_method, it would be identical to the code_challenge sent in the initial auth call.

[medwards]

I have an almost complete implementation in hrkfdn/ncspot#537 but I don't see how to turn the oauth2::AccessToken into a respot::Credentials.

[devgianlu]

Linking my implementation: librespot-org/librespot-java#356

[medwards]

OK I'm now getting MercuryError in librespot:

[2021-05-24][01:57:35] [librespot_core::session] [INFO] Authenticated as "<number>" !
[2021-05-24][01:57:35] [librespot_core::session] [DEBUG] new Session[1]
[2021-05-24][01:57:35] [ncspot::spotify] [DEBUG] worker thread ready.
[2021-05-24][01:57:35] [librespot_playback::player] [DEBUG] new Player[1]
[2021-05-24][01:57:35] [librespot_playback::audio_backend::pulseaudio] [INFO] Using PulseAudio sink with format: S16
[2021-05-24][01:57:35] [librespot::component] [DEBUG] new MercuryManager
[2021-05-24][01:57:35] [librespot_core::session] [DEBUG] Session[1] strong=3 weak=2
[2021-05-24][01:57:35] [librespot_core::session] [INFO] Country: "DE"
[2021-05-24][01:57:35] [librespot_core::mercury] [WARN] error 403 for uri hm://keymaster/token/authenticated?client_id=<custom_client_id>&scope=user-read-private,playlist-read-private,playlist-read-collaborative,playlist-modify-public,playlist-modify-private,user-follow-modify,user-follow-read,user-library-read,user-library-modify,user-top-read,user-read-recently-played

I stored the token from the oauth2 flow /w AuthenticationType::AUTHENTICATION_SPOTIFY_TOKEN (any other type wouldn't work)

[medwards]

extracted payload for the error: {"code":4,"errorDescription":"Invalid request"}

[devgianlu]

I am having the same issue as @medwards. The token doesn't work for the websocket dealer connection either: 401 Unauthorized

[sashahilton00]

Hmm, there must be something else happening after the auth code is exchanged then. Two things come to mind:

1. There's some Mercury request that needs to be discovered that makes the token usable.

2. The desktop client no longer uses mercury for communication.

Option 2 would not surprise me to be honest, as most of the clicks within the app generate corresponding http requests nowadays.

[devgianlu]

There's hm://facebook/v1/connection, but I have no idea how to see the requests for it because spotify-analyze is broken again on the latest version. I can say Mercury is still there because I see the TCP packets going to the AP address.

[roderickvd]

@ashthespy posted a shim to get started with the latest changes: #751 (reply in thread)

[ashthespy]

Doubt that is going to help, it is just to probe known mercury endpoints - spotify-analyze is a different beast based on wireshark that dumps packets from the official client.