I'm trying to understand the information at https://developer.sonos.com/build/content-service-add-features/add-authentication/use-authentication-tokens/
There's an "auth token" and there's a "private key" (from getDeviceAuthTokenResponse) which seems to be variously termed "key" and also "refresh token".
I think I understand the purpose for refresh tokens in general (i.e. something that lives forever, but isn't passed around often and isn't passed around to just everyone), but the first section in that URL above seems to indicate that the auth token and the key are both passed to just about every request.
Why should tokens be short-lived when the key, which is long-lived, is passed along in parallel, it seems. Why not then just not populate the initial private key and let the auth token live forever?
What am I missing? Are the token and private key (aka refresh token) NOT actually passed together everywhere, or is the operative word that the very original private key only ever passed (which the server can choose to change but seems pointless to include it, in the end)
You are totally right. Both the key and the refresh token are send in parallel when fetching stuff from Sonos music services.
This is also documented in my unofficial Sonos api documentation
So the answer to your question: Yes, they did not follow the general oauth2 recommendations regarding the refresh token. Normally you would also need a second request to get a new token, once the token is expired. With the Sonos music services, you just get a special xml message with the error and the new access token.
Also checkout my Sonos library for node/typescript, which has support for external music services