Using OAuth or HTTP request headers

I have written a web sources script for, but I'm facing a very annoying problem:

Due to the fact that the API for Spotify uses OAuth 2.0 there is the indispensable need for using HTTP request headers. Even when using the Client Credentials Flow you must provide atleast the Bearer Token in the header (after authorization).

Actually I solved the problem using an wrapper which is doing the authorization challenge and serving the Spotify API on localhost. In my opinion this is neither a neat solution nor a very portable solution.

As the Discogs Web Sources script already uses an OAuth mechanism, there seem to be some of the logic already implemented in Mp3tag, but not accessible for Web Sources scripts in general. Or am I missing something?

Is there a possibility to implement either the option to specify HTTP request headers manually (so one can specify the Bearer token after requesting with cURL e.g.) or a basic OAuth configuration and workflow for Web Sources scripts?


No, you're not missing something. Mp3tag is handling the Discogs Web Sources in a special way.

It would be quite some work to make this accessible to all Web Sources. How would this work for Spotify? Do you need to create an app on Spotify and grant Mp3tag access via an OAuth flow?

Yeah, that's exactly how this would be supposed to work. I would hand over the responsibility of app creation (it's not that complicated) to the user as it is much easier than to go through an application review process for generic high-usage API keys.

If I remember correctly the OAuth 2.0 flow of the Spotify Web API is fully compatible to the RFC 6749, therefore the implementation of a generic, service-independent flow should be enough.

Doing that would also doing other scripts for web APIs relying on OAuth 2.0, e.g. Soundcloud or musixmatch.

I am interested in developing a web script for a private source which also uses a Bearer token as an HTTP header. Unfortunately they have disabled the access_token query parameter. It would be great if there was an option like:

[IndexUrlHeader]=Authorization:Bearer XXXXXXXXX
[AlbumUrlHeader]=Authorization:Bearer XXXXXXXXX

We can include these options as many as we like to include more than one header for the index or album url. The header name and the header value are separated by a colon.

In this case, I chose the Authorization header as an example but these headers could be virtually anything.

1 Like

Any potential updates on how this issue can be tackled @Florian ?