Type in your question below and we'll check to see what answers we can find...
Loading article...
Submitting...
If you couldn't find any answers in the previous step then we need to post your question in the community and wait for someone to respond. You'll be notified when that happens.
Simply add some detail to your question and refine the title if needed, choose the relevant category, then post.
Before we can post your question we need you to quickly make an account (or sign in if you already have one).
Don't worry - it's quick and painless! Just click below, and once you're logged in we'll bring you right back here and post your question. We'll remember what you've already typed in so you won't have to do it again.
This idea requests the enablement of the Device Authorization Grant authentication flow, which Spotify already uses for its TV applications, for custom applications that we can register via the Developer Dashboard.
I would like to create a headless device that can remote control Spotify via the Player API.
To access that API, I need the device to be authenticated, which is cumbersome via the supported options that Spotify offers, because all options require the user to use a login form with a redirect URL.
The Device Authorization Grant flow is a great way for headless devices to offer authentication while the user can use their own browser to approve the login request.
Spotify has even built this already for its TV applications!
(image courtesy of https://pragmaticwebsecurity.com/articles/oauthoidc/device-flow.html)
The steps are:
With the client_id of a TV application, it is possible to obtain a valid token this way. Unfortunately, this does not work for custom client_id's as it seems your application needs to be allowlisted to use this flow.
Therefore, this request is to enable this flow for custom applications requested from the Developer Dashboard.
Alternatives considered:
- the Zeroconf login flow is also not supported, and seems more cumbersome than the Device Authorization Grant authentication flow.
I would very much want this for my embedded applications! I support this!
Clarification to step 1:
The request is to allow all apps to use this flow - either by letting people enable it via the dashboard or simply by removing the restriction.
Hey @hansmbakker @thebrandon45, thanks for writing up this detailed feature request! Can you say more about the headless applications you'd like to make? What will they do?
Hi @spotifyjosh,
I would like to build a Spotify Connect controller (embedded system) that can
It is not intended as a player itself, but it should control e.g. an AV receiver with Spotify Connect so that you don't need to use your phone. The NFC tags can be covered with e.g. prints of album covers.
I am adding a small OLED display to display the code that the user can enter on a pairing page like spotify.com/pair.
Examples of similar existing controllers (last one is for Sonos, but just to get the idea across):
Hi @spotifyjosh,
not sure if my reply was correctly linked to your post - hope you see this one.
I also have a use case for the OAuth2.0 device flow for a voice-controlled AI assistant to control music playback on other devices. Removing the allow list restriction entirely (or at least creating a flow in the developer dashboard similar to the quota extension request) would be very helpful in enabling this.
I am currently trying to make an Apple TV app that uses the current track playing information. However I cannot log into my Spotify account from the Apple TV as tvOS does not support web browsers. So if we could get access to the "pairing" method Spotify uses for their tvOS app it would be amazing!
@spotifyjosh
I am currently trying to make an Apple TV app that uses the current track playing information. However I cannot log into my Spotify account from the Apple TV as tvOS does not support web browsers. So if we could get access to the "pairing" method Spotify uses for their tvOS app it would be amazing!
Creating such an app is theoretically possible, but it requires developing a web application for handling tokens. Here's a simplified breakdown of the functionality:
1. **Token Generation:**
You can have your app generate a 6-digit token.
2. **User Interaction:**
Instruct the user to visit your web application.
3. **Token Input:**
Ask the user to enter the 6-digit token on your web app.
4. **Authentication Process:**
Enable the user to log in to their Spotify account using the Authorization Code Flow, with the 6-digit token as the state parameter.
5. **Token Handling:**
The access token received will be sent to the callback URI of your web app. You should store it alongside the 6-digit token that the user entered (the "state" token).
6. **Continuous Verification:**
During the login process, your app should periodically check if an access token is associated with the 6-digit token in the web app's database. This check should occur every 'x' seconds.
7. **Access Granted:**
When an access token is found, your app can grant the user access to the desired app screen.
This simplified explanation is inspired by the Device Flow schema provided at this page (previously mentioned in the main post).
Hey there you, Yeah, you! 😁 Welcome - we're glad you joined the Spotify Community! While you here, let's have a fun game and get…