Investigate automatic token setup

[gmuth]

Sources.xml tokens

We should figure out how Bose handles the automatic tokens for sources which are open for everyone but still require a token. LOCAL_INTERNET_RADIO and TUNEIN have secret tokens setup in Sources.xml. I think this is related to the service config where it says:

"authenticationModel": {
  "anonymousAccount": {
    "autoCreate": true,
    "enabled": true
  }
}

[timvw]

Some findings from my deployment that relate to this:

Spotify Connect re-authenticates the speaker's embedded Spotify client. When you cast from the Spotify app to the speaker, Spotify Connect authenticates the speaker directly over the local network via ZeroConf/mDNS. This creates a fresh Spotify session in the speaker's RAM.

After that, Spotify presets work — even through soundcork. The session is in-memory only; the OAuth token in Sources.xml doesn't change.

What this means for automatic token setup: The Spotify token management is split between two systems:

1. Spotify Connect handles its own authentication (local network, no Bose servers)
2. The SoundTouch Spotify integration used Bose's Spotify client ID (via marge) for OAuth — this path is effectively broken since the SoundTouch app can't reconnect accounts

So "automatic token setup" for Spotify may not be feasible through soundcork alone. But the workaround (play one song via Spotify Connect first) is reliable and only needs to be repeated after a speaker reboot.

More details: https://github.com/timvw/soundcork/blob/main/docs/spotify.md

[timvw]

Update: We found a way to fully automate Spotify priming — no manual interaction needed.

My earlier comment described needing to "play one song via Spotify Connect first." We've since discovered how to do this programmatically.

The discovery

Using Wireshark, we captured the traffic between the Spotify desktop app and the speaker's ZeroConf endpoint (port 8200). The key finding: the desktop app sends a plain Spotify access token — no encryption:

POST http://speaker:8200/zc
Content-Type: application/x-www-form-urlencoded

action=addUser
userName=<spotify_user_id>
blob=<raw_spotify_access_token>
clientKey=
tokenType=accesstoken

Two mechanisms — serving different purposes

1. ZeroConf Primer (cold boot activation)

On cold boot, the speaker does NOT request a Spotify token. The ZeroConf primer proactively pushes a fresh token via addUser to port 8200 after the power_on event. This is what actually activates Spotify on a freshly booted speaker.

2. OAuth Token Intercept (ongoing refresh)

Once the speaker has an active Spotify session, it periodically refreshes its token by calling POST /oauth/device/{deviceId}/music/musicprovider/15/token/cs3. Soundcork handles this transparently. Same approach as @julius-d's ueberboese-api.

What didn't work (dead ends)

• DH + AES encrypted blobs — speaker returns 101 but activeUser stays empty
• Librespot stored credentials — accepted but never activates
• The original OAuth token from Sources.xml — dead

Implementation

Both approaches are in my soundcork fork — see PR #185. Tested end-to-end from cold boot.

See also #107 which reports the same Spotify preset issue.