Announcements

Help Wizard

Step 1

NEXT STEP

Device Authorization Grant authentication flow for custom applications

Device Authorization Grant authentication flow for custom applications

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!

Spotify Pair page (courtesy of https://pragmaticwebsecurity.com/articles/oauthoidc/device-flow.html)Spotify Pair page (courtesy of https://pragmaticwebsecurity.com/articles/oauthoidc/device-flow.html)

(image courtesy of https://pragmaticwebsecurity.com/articles/oauthoidc/device-flow.html)

 

The steps are:

  1. the device can request a code to present to the user via https://accounts.spotify.com/oauth2/device/authorize using
    • the application's client_id
    • the desired scope
  2. the user can fill out this code on https://spotify.com/pair and approve login
  3. the device then fetches the token from https://accounts.spotify.com/api/token using
    • grant_type = urn:ietf:params:oauth:grant-type:device_code
    • device_code from response to the earlier authorize request
    • the application's client_id

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.

Reply
9 Replies

I would very much want this for my embedded applications! I support this!

Clarification to step 1:

  • if your app is not allowlisted, the response you get is:
    {
    "error": "unauthorized_client",
    "error_description": "Client not allowed"
    }
  • an allowlisted app gets this response:
    {
    "device_code": "<redacted>",
    "user_code": "<redacted>",
    "verification_uri": "https://spotify.com/pair",
    "verification_uri_complete": "https://spotify.com/pair?code=<redacted>",
    "expires_in": 3599,
    "interval": 5
    }

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

  • select albums etc. by reading NFC tags
  • control playback (play / pause / next / previous / change shuffle mode)
  • change volume

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).

Suggested posts