TokenType authorization_code

[kingosticks]

I randomly dumped the getInfo response from my Sonos Roam and noticed it was sending tokenType":"authorization_code" along with a clientID and all the usual stuff. I've not yet tried it with this tool to see what happens when I respond with an access token. Has anyone got this flow working?

[TimotheeGerber]

I don't have any official Spotify hardware. So I did not have the chance to test this tool on a device sending tokenType":"authorization_code". But keep in mind that 4 different authentication methods are proposed. You can switch the authentication mechanisms with the --auth-type flag followed by one of the 4 possibilities: reusable, password, default-token or access-token. Maybe one of them will let you connect on your Sonos Roam.

If it is not the case, you can try to intercept the traffic between the official client and your receiver. Or you can create a false receiver and try to connect with the official client to get the information it is sending. It would help to develop another authentication mechanisms if needed.

[kingosticks]

Yep, I'll give it a go. Although I suspect it'll need some extra code. Maybe we need to use the Hermes code endpoint (which librespot doesn't (yet) expose).

[kingosticks]

Unfortunately, not much progress. I couldn't get my Android client to do the addUser when using "tokenType": "authorization_code" unless I also use "clientID": "9b377073ea334637b1406f329ce005de" in my getInfo response. This is the client ID my Sonos Roam was returning in its getInfo response. I tried a bunch of other client IDs (keymaster, Android client, my own) but the Android client didn't seem to like them. Maybe there's a list of client IDs that are allowed to use this auth method.

When using the working clientID, the addUser request I got was:

{
  "action": "addUser",
  "blob": "AQC_0P91EOZDXSVldrLKtt5l1NoEecy8lvNvUF_wPXnZ8iPd22wq4lSA3xk4_WKxl4bmIsqz_-jYngzxoPwaSK.......Q3g",
  "clientKey": "",
  "deviceId": "f2eb0c419582c0b6690fa9ad4999b1b758ad38a3",
  "deviceName": "Pixel 6a",
  "loginId": "a969e0be850f......dc38f265a725",
  "tokenType": "authorization_code",
  "userName": "kingosticks4",
  "version": "2.7.1"
}

Maybe that's helpful to someone down the line who makes more progress.

[kingosticks]

I used mitm proxy to see what my desktop client was doing in response to "tokenType": "authorization_code". The client makes a POST request to https://accounts.spotify.com/api/token to exchange its (access?) token into an authorization_code. It sets a bunch of params, one of which is audience with the value taken from clientID in my getInfo response.

If I use the Sonos client ID, the client receives a valid response and it sends me the returned token in the blob field of its subsequent addUser request:

{
    "access_token": "AQC6oYY86uub...........................AGbcbx47Kvw",
    "expires_in": 600,
    "issued_token_type": "urn:spotify:params:oauth:authorization_code",
    "scope": "streaming",
    "token_type": "Bearer"
}

But if I use any other client ID, the client gets the following and gives up:

{
    "error": "invalid_target",
    "error_description": "audience: not supported"
}

For librespot, we could probably hardcode the Sonos client ID in getInfo responses for this token type. For the other side (something like this tool), we'd need to add support for converting credentials into an authorization_code. Either via HTTP (like my desktop client did) or maybe via Hermes (old way?) using the keymaster (hm://keymaster/code???). I'm not sure I care enough to do either but I had fun investigating and maybe useful for someone else.

[TimotheeGerber]

I also noticed that Spotify is usually making some checks on the clientID. It is not possible to send something gibberish or a known clientID. It would be refused.

Thanks for your research! Currently, I don't have time to code and test something. If you or anyone ever find the need for and the time, don't hesitate to make a PR!

[kingosticks]

No problem, I'll probably add some of this to the librespot docs at some point.

[thlucas1]

Just curious if anyone has made progress on handling the tokentype=authorization_code type of requests?

It sounds like the client is exchanging an access token for an authorization_code token. If that is the case, isn't the access token bound to a specific clientId (Sonos constant of 9b377073ea334637b1406f329ce005de) and clientSecret (unknown / not public knowledge) value? You would need access to the access token that was generated for that clientid, which is stored on the client itself. In other words, I don't think you could generate an access token for that clientId without knowing the clientSecret value, no?

[TimotheeGerber]

No progress from my side. I don't have any official receiver, so I can't try anything. Sorry and good luck!

[thlucas1]

@TimotheeGerber
Thanks for replying. I currently don't have any Sonos devices either, but am in the process of getting a Sonos Symphonisk device. Will keep you posted.

[kingosticks]

So, reading again what I wrote last year, I think I must have been confused...

The client makes a POST request to https://accounts.spotify.com/api/token to exchange its (access?) token into an authorization_code

I'm not sure what I was thinking here. You cannot exchange a short-lived access token for an authorization code, that makes no sense. Surely the client was grabbing a new access token to then pass on to the sonos device for it to use. On top of this there is sanity checking of the audience parameter, for some reason?

So in theory the player should be able to use the access token with the Spotify Web API. In my efforts at librespot-org/librespot#1098 I had lots of problems using that access token. However, I was trying to do something more complicated than simply use it for Web API requests, it might work just fine for that. I hope that makes sense.

[thlucas1]

I guess my biggest question is what's in the Spotify Connect Zeroconf API addUser blob for tokentype=authorization_code?

I know the blob layout for the tokenType=default (seems to work for tokenType=accesstoken as well):

blob = bytearray()
write_int(0x49, blob)                           # 'I'
write_bytes(self.credentials.username, blob)    # username
write_int(0x50, blob)                           # 'P'
write_int(self.credentials.auth_type, blob)     # auth_type (0x00)
write_int(0x51, blob)                           # 'Q'
write_bytes(self.credentials.password, blob)    # password

One would think it would be some sort of serialized token, instead of a formatted blob structure?

My only goal at this point is to "wake" the Sonos device up, so that it will be listed in the Spotify Connect active device list. The fact that it is implementing the Spotify Connect Zeroconf API endpoints (addUser, resetUsers, and getInfo) tells me that it's possible.

[kingosticks]

I think the format is the same except password is replaced with access token. I vaguely remember dumping it out and the "access token" I got looked vaguely sensible. I think (I don't remember exactly) that's what I implemented in the PR I linked. I could try and resurrect this but time is more scarce these days.

[thlucas1]

@kingosticks
Thanks for the info.

Regarding the access token, can you recall if:

• was it for a Spotify Webservices API access token? If so, there should have been a request made to https://accounts.spotify.com/api/token to request / renew a Spotify authorization token.
• was it for a Sonos Control API access token?

I would assume that it's a Spotify Webservices API access token, and am also assuming that it should have the streaming scope (or whatever is returned by the getInfo action response)?

I reviewed the PR changes, but did not see anything Sonos specific in that code. Note that I am not too familiar with librespot though, so no surprise there. I'm learning though!

[kingosticks]

It was a Spotify Web API token, my earlier post specifies the endpoint and the scope. Everything here is about Spotify, it just happens to be running on a Sonos device.