Recently, concerns were raised on Reddit about Cast to Sonos's OAuth implementation and security practices. I'm genuinely happy that someone took the time to look at the extension critically, as it gives me the opportunity to explain the architectural decisions and security measures that went into building it.
I want to address each of these concerns transparently and provide insight into why certain technical choices were made.
Addressing the Concerns
Unnecessarily uses cloud-based OAuth authentication
This is actually how the extension originally started: as direct casting. This was the ideal setup, as it didn't require a proxy server. The concern mentions that playback control over local APIs is possible (UPnP or HTTP), but to my knowledge this is not officially supported, is unreliable, and varies per speaker model. Because of this, it's not possible to implement it in a consistent and dependable way.
While it is technically possible, it would require a local HTTP server. A Chrome extension cannot start a local server, so you would need a separate program running on the user's machine. Additionally, the Sonos Control API is explicitly designed to facilitate communication and synchronization between speaker groups, users, and services.
The alternative would be allowing a Chrome extension direct access to devices on the local network, which in my opinion is far more dangerous. In theory (and this is not something I control), Sonos allows easy monitoring and token revocation, enabling users to instantly revoke access. You can already effectively do this by deleting the extension data, since all access tokens are stored only in the browser's extension storage—not on an external server (I'll come back to this later).
The connection to Sonos uses standard HTTPS. Securing inter-service communication on localhost—especially between two different services—is actually not as straightforward as it may seem. Using publicly exposed APIs is generally considered best practice.
I don't understand why OAuth is considered an "issue." In my opinion, it's actually an excellent solution, and this use case is exactly what it was designed for.
Does not appear in Sonos's official app or web dashboard
In my communications with Sonos, I have not yet achieved an official partnership, but I am actively working toward it.
Grants extensive and indefinite control
To my knowledge, playback-control-all is the only allowed scope according to Sonos documentation: https://docs.sonos.com/docs/authorize
The concern about the inability to easily revoke access is completely valid. I strongly agree that Sonos should list OAuth integrations alongside other third-party connections in their app so users can disconnect at any time.
That said, you can rest assured that:
- Tokens are stored directly using Google's extension storage
- Only short-lived access tokens are sent
- The refresh token (the one that actually matters) is only sent when a new access token is requested
All of this traffic is encrypted over HTTPS, including requests from the proxy server to the Sonos API.
Routes audio streams through external servers
To cast audio, Sonos requires a URL. Unfortunately, Chrome extensions cannot spin up an HTTP server. While they can communicate directly with Sonos speakers, they cannot act as the server hosting the audio data. To solve this, I use streaming servers hosted on Hetzner Cloud infrastructure, which is ISO 27001 certified.
Early in development, I considered requiring users to download a separate program that would spin up a local server to stream audio. However, even ignoring the impracticality of streaming directly over local networks (network settings, misconfigurations, VPN usage, etc.), how secure would it really be to ask users to download and run an executable with local network access?
Conclusion
I currently fail to see anything significant that I could improve upon. That said, I welcome any requests for code or infrastructure audits for those who still have concerns about the details outlined above.
I truly appreciate the feedback and the time that clearly went into it. These are all topics I've thought deeply about myself, and it's reassuring to know I'm no longer the only one. Feedback and suggestions are always welcome.
I have also been working in parallel on an AI integration for Sonos, which would store tokens in a database. The advantage would be that users wouldn't be sending Sonos tokens (even encrypted over HTTPS) directly, but instead using intermediary tokens. However, this analysis has made me rethink that approach.
I always aim to apply a layered defense strategy—never relying on a single security mechanism, but instead combining multiple layers of protection.
Even this relatively long post fails to capture everything I do to keep the extension safe, like the privacy options in the extension and all the work that has gone into the backend systems. A lot of this information can be found on the casttosonos.com website.
Looking Forward
If you have any questions or concerns about the security of Cast to Sonos, please don't hesitate to reach out through the feedback form. I'm committed to transparency and continuous improvement of the extension's security practices.
Happy New Year to all Cast to Sonos users! Here's to a secure and enjoyable 2025! 🎉