Support Spotify OAuth token refresh (POST /oauth/device/{deviceId}/music/musicprovider/15/token/cs3)

[timvw]

Device trigger

Speaker has an active Spotify session (from a previous Spotify Connect cast or ZeroConf priming). When the access token approaches expiry, the speaker periodically calls this endpoint to refresh it. Observed during active Spotify playback.

Request

POST /oauth/device/000C8AB02519/music/musicprovider/15/token/cs3
Host: <soundcork server>

Originally sent to streamingoauth.bose.com. Since soundcork already intercepts the marge domain, and the speaker derives the OAuth URL from the same base domain, this request arrives at soundcork without any extra DNS configuration.

Expected response

200 OK
Content-Type: application/json

{
  "access_token": "BQ...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "streaming user-read-email user-read-private"
}

Current behavior

404 Not Found — no route defined for /oauth/... paths.

Notes

• Provider ID 15 = Spotify (matches the provider list from /streaming/sourceproviders)
• Token type cs3 = Bose credential schema version 3 (token_version_3 in Sources.xml)
• The speaker firmware manages its own refresh cycle — this is transparent to the user
• Requires a linked Spotify account with a valid refresh token on the server side
• Captured via tshark during active Spotify playback on a SoundTouch 20 (firmware 27.0.6)
• Implementation available in PR Add Spotify support with OAuth intercept and ZeroConf primer #185

Related: #107, #159

[gmuth]

Now that's interesting! Could you please explain how the device derives the oauth URL from the base domain? What happens when I use http://soundcork:8000/marge? (I configure IPs elsewhere)

I've saw those urls but can not associate a use case - I guess they are not related

BoseApp: https://streamingefeintoauth.bose.com
BoseApp: https://streamingintoauth.bose.com

[timvw]

Good question! The speaker's SoundTouchSdkPrivateCfg.xml has <margeServerUrl> but no separate <oauthServerUrl>. The OAuth requests go to the same base domain as marge.

In production, the speaker would call https://streaming.bose.com/oauth/device/{deviceId}/... — same host as the marge endpoints. When you rewrite <margeServerUrl> to point at soundcork (or your server), the OAuth requests come along for free.

So if your config uses http://soundcork:8000/marge, the speaker should call http://soundcork:8000/oauth/device/{deviceId}/music/musicprovider/15/token/cs3. The /marge prefix is only on the marge-specific paths; the OAuth path starts at /oauth/... on the same host:port.

Regarding those two URLs:

streamingintoauth.bose.com   → INT = Integration (Bose internal test environment)
streamingefeintoauth.bose.com → EFE = End-to-End test environment

These are Bose's internal/development domains — not used by production devices. They're embedded in the firmware binaries alongside their staging (streamingstg.bose.com) and test proxy (bose-test.apigee.net) counterparts. See gesellix/Bose-SoundTouch UPSTREAM-URLS.md for a comprehensive list extracted from firmware analysis.

[akpdw]

Hey @timvw , a question about that oauth endpoint: I've configured a Spotify source (faked-up, in that I created it after Bose's Spotify account configuration stopped working), but I can't seem to get my speaker to call the oauth endpoint. In fact, I don't see my speaker making a call to any host at all.

Looking at the logs on my device with logread | grep -i oauth I see

Feb 28 15:23:42 spotty local0.info STSCertified[1821]: [(002317):SpotifyClient:INFO]IsLoggedInOAuthCb: isLoggedIn=false user=(my spotify id) accessTokenExpired=true
Feb 28 15:23:42 spotty local0.info STSCertified[1821]: [(002317):STSOAuth2:INFO]RetrieveAccessToken: 
Feb 28 15:23:42 spotty local0.info STSCertified[1821]: [(002317):STSOAuth2:INFO]ConstructUrl:  url:/oauth/device/(my device id)/music/musicprovider/15/token/cs3
Feb 28 15:23:42 spotty local0.info STSCertified[1821]: [(002317):STSOAuth2:INFO]ConstructPostDataString: postData:code=&grant_type=refresh_token&redirect_uri=&refresh_token=(my fake token)
Feb 28 15:23:42 spotty local0.warn STSCertified[1821]: [(005776):SimpleURLFetcher:WARNING]URL Fetch ('/oauth/device/(my device id)/music/musicprovider/15/token/cs3') failed with CURL ErrorCode 3

CURL error code 3 is what I get when I run curl directly without a protocol/host, like if the URL being passed were literally /oauth/device/...

So that's acting like I don't have an OAuth2 base host configured. Any idea where that could be coming from?

(copying @julius-d since ueberbose also has Spotify support)

[gesellix]

Not sure if that's relevant: I changed the resolve.conf / DNS setup so that everything is routed to the replacement service. OAuth requests are then captured and can be cut short.

[akpdw]

@gesellix The thing here is that I don't see the request going anywhere at all -- it generates an incomplete URL and then errors out. No way to hack the hostname resolution if there's no hostname. (I looked through the tcpdump logs and didn't see any outgoing requests that I didn't recognize, so that tracks with there just being no hostname there.)

[gmuth]

Maybe the base-url is taken from SoundTouchSdkPrivateCfg.xml/margeURL only (ignoring OverrideSdkPrivateCfg.xml)

[gesellix]

A recorded request/response looks like below. I also didn't find any place where the target host is definied (not even in binaries, so that's really strange).

### POST https://streamingoauth.bose.com/oauth/device/<device>/music/musicprovider/15/token/cs3
POST https://streamingoauth.bose.com/oauth/device/<device>/music/musicprovider/15/token/cs3
Host: streamingoauth.bose.com
User-Agent: Bose_Lisa/27.0.6
Accept: */*
Authorization: <redacted>
X-Forwarded-For: 192.168.178.35
Content-Type: application/json
Content-Length: 208

{"code":"","grant_type":"refresh_token","redirect_uri":"","refresh_token":"<redacted>"}

> {% 
    // Response: 200 OK
    // Headers:
    // Content-Length: 610
    // Request-Id: 319c32d6-3229-43db-8fc2-3f2b779b72b0
    // Content-Type: application/json
    // Date: Thu, 26 Feb 2026 16:35:41 GMT
    // Strict-Transport-Security: max-age=31536000
    // X-Amz-Cf-Pop: DUS51-P6
    // Set-Cookie: __Host-device_id=<redacted>;Version=1;Path=/;Max-Age=2147483647;Secure;HttpOnly;SameSite=Lax
    // Set-Cookie: sp_tr=false;Version=1;Domain=accounts.spotify.com;Path=/;Secure;SameSite=Lax
    // X-Content-Type-Options: nosniff
    // X-Proxy-Origin: upstream
    // Vary: Accept-Encoding
    // X-Amz-Cf-Id: <redacted>
    // Server: envoy
    // X-Envoy-Upstream-Service-Time: 53
    // X-Cache: Miss from cloudfront
    // Via: HTTP/1.1 fringe, HTTP/2 edgeproxy, 1.1 google, 1.1 ca9f3841ca2bd61788b6781e41891042.cloudfront.net (CloudFront)
%}

/*
{"access_token":"<redacted>","token_type":"Bearer","expires_in":3600,"scope":"playlist-read-private playlist-read-collaborative streaming user-library-read user-library-modify playlist-modify-private playlist-modify-public user-read-email user-read-private user-top-read"}
*/

[gesellix]

No way to hack the hostname resolution if there's no hostname

My service acts as DNS server, which allows me to hook into the speaker's DNS resolution. Any queried hostname appears in my logs, and I can decide whether to delegate lookups to an upstream DNS server or direct to the service itself. In other words: it's less of a hack and more about hooking at a deeper level to gain more control. I started with modifications of /etc/hosts, but changing /etc/resolv.conf was more effective.

[gmuth]

@gesellix, could you provide the dns config as a docker setup? Maybe bind?
This could be added to the docker compose setup also including the ETag workaround - see #220

[gesellix]

Unfortunately I can't provide a generic dns config, because the soundtouch-service itself is a DNS server. See https://github.com/gesellix/Bose-SoundTouch/blob/6ee0fc8115f3715aba58e7f362104a2505a710b2/pkg/discovery/dns.go#L156 for the relevant part of the implementation.

Maybe Soundcork could also become a DNS server using dnslib.

If a more generic approach using containers is required, a setup like this based on CoreDNS could work (this is based on a suggestion by Claude.ai, I didn't test it, yet):

Corefile with example host names, using soundcork as redirect target:

bose.com:53 bosecorp.com:53 {
    template IN A {
        answer "{{ .Name }} 60 IN CNAME soundcork."
    }
    log
}

.:53 {
    # Docker's internal DNS resolver
    forward . 127.0.0.11
    log
    errors
}

docker-compose.yaml:

services:
  soundcork:
    image: deborahgu/soundcork:version
    networks:
      - bose-net

  dns:
    image: coredns/coredns
    volumes:
      - ./Corefile:/Corefile:ro
    ports:
      - "53:53/udp"
      - "53:53/tcp"
    networks:
      - bose-net
    dns: 127.0.0.11   # use Docker's internal resolver for upstream

networks:
  bose-net:

[gmuth]

In production, the speaker would call https://streaming.bose.com/oauth/device/{deviceId}/... — same host as the marge endpoints. When you rewrite <margeServerUrl> to point at soundcork (or your server), the OAuth requests come along for free.

You also mentioned "Originally sent to streamingoauth.bose.com" which is different.

I found this format string in BoseApp:

$ grep "setting oauth url" /opt/Bose/BoseApp 
%s setting oauth url to %s from %s
%s setting oauth url -2 to %s from %s

@timvw, could you please provide logs showing this message and it's context (+/- 15 lines)?

Maybe the algorithm to build the oauth url is incompatible with IPs and requires a FQDN.
@akpdw, you could setup /etc/hosts such that you can still use the original Bose domain names.

[akpdw]

Oh so an update on this: I have made some new discoveries, though as of right now I haven't gotten things working yet.

It occurred to me that it was likely that Amazon also used oauth, so I tried setting up my old Amazon account to work with SoundTouch. Unlike the Spotify setup,that still works, and indeed does use oauth. So I switched over to soundcork, copied over the Amazon configuration, and this time got in the logs

Mar  2 11:29:34 spotty local0.info BoseApp[1820]: [(002016):MargeClient:INFO]AuthServerInfoRequestCB setting oauth url to http://192oauth.168.0.231:8000/marge from http://192.168.0.231:8000/marge

lol so that wasn't going to work, but at least it was something. Anyway set up a host entry in DNS for soundcorkoauth on my local network and pointed my device to running against our actual install instead of a test install on my laptop, and voila! I was actually able to get requests to come into /marge/oauth/device/{deviceId}/music/musicprovider/20/token/cs3.

Unfortunately, adding a Spotify service in there along with the Amazon service still didn't work -- I actually got URL Fetch ('/oauth/... musicprovider/15 messages in the log file along with URL Fetch ('https://soundcorkoauth.../marge/oauth/... musicprovider/20 messages. So apparently the Amazon and Spotify subsystems get their oauth urls individually?

The two pieces that I'm going to look at next are the mysterious /streaming/device/{device_id}/streaming_token endpoint -- I did end up seeing calls to that endpoint when I configured the Amazon source, and put in an implementation to return 200 and a bogus Authorization header, but I'm not sure what role it plays in this -- and the secret configuration. The Amazon token is in a very strange format, looking like

<source secret='{&quot;AmazonSecret&quot;:{&quot;refresh_token&quot;:&quot;{token}&quot;,&quot;site_id&quot;:&quot;1772322623&quot;}}' secretType="token">

Since I still haven't had anyone verify what a valid Spotify configuration looks like, I haven't been able to test if the format of the secret has any effect on the behavior of the rest of the system. Possibly if the token isn't correctly formatted the oauth url is never set?

Will continue exploring as time allows. But wanted to give an update.