API authorization failed

[eutialia]

So after deploying it to my CF workers I keep getting this error from my unifi system:

 Temporary error in DDNS server response: DDNS server busy, try later

After some digging I found that it's because of how the script tries to authenticate itself by attaching the token in the header:

unifi-ddns/src/index.js

Line 63 in 7e12b8a

Authorization: `Bearer ${this.token}`,

This will lead to an API error from the CF:

{
  "success": false,
  "errors": [
    {
      "code": 6003,
      "message": "Invalid request headers",
      "error_chain": [
        {
          "code": 6111,
          "message": "Invalid format for Authorization header"
        }
      ]
    }
  ],
  "messages": [],
  "result": null
}

If I change the headers to include both X-Auth-Email and X-Auth-Key following the documentation, everything works as expected. I'm just not sure if this is due to some configuration error on my account, or CF has updated their API authorization logic.

[Dex1000]

Hi
I'm not the best with this kind of tinkering, what exactly did you modify within within index.js?

[MatthewA1]

I think your problem is with some configuration on your account. CloudFlare's API documentation makes the authentication methods for endpoints very confusing, but tokens are not only an allowed method, but are in fact the preferred method due to the ability to tightly restrict their scope.
Up until sometime in April or May 2023, Bearer Auth was still listed as a valid security option for the DNS endpoints; why it was removed from the documentation I have no idea. (See this snapshot from April 2023)
In the experimental new version of the API documentation, Bearer Auth still isn't listed as a method, but they changed the description for "API Email + API Key" authentication to make the usage of API keys vs tokens more clear:

The previous authorization scheme for interacting with the Cloudflare API, used in conjunction with a Global API key.
Example: X-Auth-Email: [email protected]
The previous authorization scheme for interacting with the Cloudflare API. When possible, use API tokens instead of Global API keys.
Example: X-Auth-Key: 144c9defac04969c7bfad8efaa8ea194

This community post by a CloudFlare employee confirms tokens are definitely the preferred method for API access, and in fact they are adding a account based tokens in addition to the user based tokens.

TL;DR

Tokens are still supported and in fact preferred, just the API docs don't make that clear so it's harder to find a definitive answer than I would have thought.

So were you originally trying to use an API token or an API key with the worker? Your Global API Key will definitely not work with this worker for the reasons you noted with the different headers that are used for the API key.
If you were trying to use an API token: What permission and resources did you assign to that token? Did you apply client IP address filters?

[chucklebrother]

FWIW I have this working using an account level bearer API token, and bearer tokens are the way to go.

Using the global account keys is definitely depreciated on CF platform, and they are something of a security anti pattern as anything using your global keys is operating in the entirety of your user's security context. Unlike a API token which has a scope, and hopefully a tightly focused scope as suggested in the configuration guide.

Cloudflare's API documentation could certainly use some improvement. That they have removed the instructions for using and the code examples featuring bearer token authentication from the current documentation, and omitted it from the new API documentation while stating that API keys are deprecated, is, frankly, insane.