Client Credential auth flow: 400 Bad Request (local browser JS)

[jsejcksn]

Issue found on 8 August 2017.

Endpoint(s):

• Auth flow: POST https://accounts.spotify.com/api/token/

Scope(s):

• None (application is not using authentication)

Steps to reproduce:

See code at this gist

Expected behaviour:

A token is returned.

Actual behaviour:

400 Server Error (consistently)

---

At this point, I'm simply trying to get a token using the Client Credentials flow. The code is running in a page locally on my computer (so that my client keys aren't exposed to the world). I have included below the content of the linked gist for convenience. Although I can use the curl method successfully, this method fails. One person attempted to help me troubleshoot in issue #321, but without success, so I'm hoping for a repo member to offer a suggestion.

Please advise. Thanks.

---

Included in an html file using <script src="js/spotify-test.js"></script>:

(() => {

  const myClientInfo = { // but using actual client ID and secret values
    clientID: '<client_id>',
    clientSecret: '<client_secret>'
  };

  const myAuthUrl = new URL('https://accounts.spotify.com/api/token');

  const myAuthHeaders = {
    'Content-Type': 'application/x-www-form-urlencoded',
    Authorization: `Basic ${btoa(`${myClientInfo.clientID}:${myClientInfo.clientSecret}`)}` // Won't work for unicode characters, but I think the Client ID is always ASCII
  };

  const myAuthQueryParams = {
    grant_type: 'client_credentials'
  };

  let myAuthFormBody = new FormData();
  appendObjToFormBody(myAuthQueryParams, myAuthFormBody);

  const myAuthInit = {
    method: 'POST',
    headers: myAuthHeaders,
    body: myAuthFormBody,
    mode: 'no-cors'
  };

  const myAuthRequest = new Request(myAuthUrl, myAuthInit);

  fetch(myAuthRequest)
  .then(res => {
    if (res.ok) {
      return res.json();
    }
    throw new Error('Network response was not ok.');
  })
  .then(data => console.log(data))
  .catch(err => console.log(`Fetch problem: ${err}`));

  function appendObjToFormBody (obj, form) {
    for (let prop in obj) {
      if (obj.hasOwnProperty(prop)) {
        form.append(prop, obj[prop]);
      }
    }
  }

})();

[hughrawlinson]

Hi! Whoa there, I didn't realise you were making this call on the client side in your last issue - you can't run the client credentials auth flow directly from the client side as it requires the client secret to be available in plaintext (or close to it), which isn't safe in a browser environment. We suggest that you do the client credentials flow on a server, and then within your own authentication/authorization scheme you request Spotify data through your server.

If your client ID and secret appear in JS source, anyone could just grab them and authenticate as your app! If this happens, if your client secret has ever appeared in public source, you can go into your app settings on developer.spotify.com and regenerate your client secret, which will break any new attempts to authorize with that pair, and provide you a new secret to use and not expose.

If you need to authenticate entirely from the client side and don't have access to a server, have a look at the implicit grant flow. It authorizes a user returning a temporary access token, and doesn't require a client secret.

Hope that helps!

[jsejcksn]

Hi @hughrawlinson:

First, thanks for responding! Your response leaves me with some follow up questions and makes me realize that perhaps I also need to supply more information:

We suggest that you do the client credentials flow on a server

I am running this on an http server on my LAN.

If you need to authenticate entirely from the client side and don't have access to a server, have a look at the implicit grant flow. It authorizes a user returning a temporary access token, and doesn't require a client secret.

My goal is to be able to use the API on a variety of personal devices on my LAN to retrieve metadata without having to login to my account on every device. There is no jeopardy of client key exposure in this scenario.

So now my questions:

When you said

you can't run the client credentials auth flow directly from the client side

1. what exactly did you mean by can't? Is there something on the Spotify end that refuses certain kinds of requests?

2. What is the specific criteria for acceptance? I spent quite a bit of time trying to work this out because the documentation does not list any such restrictions.

3. You also mentioned this:

If your client ID and secret appear in JS source, anyone could just grab them and authenticate as your app!

You're absolutely right—as is, this is true. It would be great if Spotify would implement key restrictions to help mitigate when this happens. Below is an example screenshot from the Google Cloud Platform API key details page. Should I post this as a separate enhancement issue?

I'm looking forward to your replies.

[hughrawlinson]

Hi @jsejcksn:

1. what exactly did you mean by can't? Is there something on the Spotify end that refuses certain kinds of requests?

CORS will restrict you from making the client credentials request from your browser.

2. What is the specific criteria for acceptance? I spent quite a bit of time trying to work this out because the documentation does not list any such restrictions.

CORS in particular, but here's some documentation from Slack talking about their recommended best practices for client secret storage. In short - you should treat your secret key like a private SSH key or a password; it's not a good idea to publish it in plain text on a http server.

There's no specific rules from us on what's allowed or not allowed when it comes to storing and securing your client secret - but you should keep it safe, because if someone compromises your client key & secret pair they can make requests as your app. If your app is detected behaving maliciously, we may suspend your app entirely, breaking it in production.

3. Key Restrictions

A separate issue for that would be good.

---

Additionally, it seems that I may have slightly misunderstood:

We suggest that you do the client credentials flow on a server

I am running this on an http server on my LAN.

Are you making the request from a webpage that's being served from a http server on your lan, or are you making the request serverside on that server? Client credentials should work serverside, and I'm very happy to help you debug if they're not! They're not expected to work client side because of CORS restrictions to discourage developers from leaking their client secrets in their web apps.

---

My goal is to be able to use the API on a variety of personal devices on my LAN to retrieve metadata without having to login to my account on every device.

For this use case, I'd suggest building a small proxy app that contains your client id and secret, as well as a personal refresh token obtained through the Authorization Code flow, and handle token refreshes here, proxying calls to the Spotify API through this server, making sure to only listen to traffic on your local network, and making sure to be super vigilant about network security. The advantage of this approach is that your credentials are all stored in one place, and that place is not a client whose source can easily be inspected.

Hope that helps!

[jsejcksn]

@hughrawlinson I think I understand.

1. So am I correct in understanding that Spotify has no plans whatsoever to enable CORS for the API token request?

2. If that's correct, then how can I use the API without incurring additional cost in the case that I only have access to a Chromebook (which has no server capabilities beyond serving http) and a couple of mobile devices?

[hughrawlinson]

@jsejcksn:

1. Yes, that's correct - we don't allow CORS calls to the accounts.spotify.com service because that will encourage developers to store their client secrets insecurely, which is bad because they should be considered as sensitive as (or more sensitive than) passwords.

2. You can use the Implicit Grant flow which does not require a client secret, and can be implemented entirely client side. The access tokens from Implicit Grant last 1h and are not refreshable. It seems you have some options for running servers on your chromebook in developer mode if you need to use the client credentials grant, otherwise I'd recommend the Heroku free tier as a platform for running your backend code.

[jsejcksn]

@hughrawlinson Thanks for clarifying. Can you add the bit about no CORS support to the auth flow documentation page on the Spotify site?

[hughrawlinson]

Will do, thanks @jsejcksn :)

[jsejcksn]

@hughrawlinson Just checked back to the page on the Spotify site and don't see any mention regarding CORS. In your last comment, you said it would be updated. Did you encounter an issue?

[filipegorges]

Sorry to intrude,

I was beating my head with this as well for an hour or so until I've found this issue...
Is it possible to add a quick note at documentation somewhere to remind people that they can't add auth on a simple front-end or something (except for the temporary auth token, of course)? Any mention of CORS would already be of great help.

I was building a little toy-app so security wasn't an issue and all of this won't really impact on anything, but still, if there was any mention of it on the documentation it could have saved some time :)

Thanks!