OAuth 1.0a "Invalid signature" on Request Token — signature verified byte-for-byte against oauthlib, common double-encoding bug already ruled out

[ksenov Speed Up]

Hello,

I'm implementing the full 3-legged OAuth 1.0 flow (per platform.fatsecret.com/docs/guides/authentication/oauth1/three-legged) to access the Food Diary for an existing fatsecret.com member account.

My Consumer Key: a3a1f1c17dbc468f9c940934b626ec07

I consistently receive Invalid signature (HTTP 400) on POST https://authentication.fatsecret.com/oauth/request_token.

What I've already verified/ruled out:

1. Consumer Key and Consumer Secret copied correctly — no whitespace, correct length (32 chars), correct hex character set
2. Reset the Consumer Secret once to rule out a stale/leaked value (previously accidentally shared, now rotated)
3. System clock accurate — oauth_timestamp matches current time
4. Independently verified my signature calculation against oauthlib (the reference Python OAuth1 implementation) — both produce the exact same signature for identical input parameters
5. Specifically ruled out the double-encoding bug described in your forum thread (OAuth Request Token Error - 500 Response), where the normalized parameter string must be percent-encoded a second time as the third segment of the signature base string. My implementation already does this correctly — confirmed by matching oauthlib's output character-for-character.

Example signature base string (Consumer Secret redacted):

POST&https%3A%2F%2Fauthentication.fatsecret.com%2Foauth%2Frequest_token&oauth_callback%3Doob%26oauth_consumer_key%3Da3a1f1c17dbc468f9c940934b626ec07%26oauth_nonce%3DMQInQuXS6odeFvrJZx92sU2R6VT1cEwQ%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1786407250%26oauth_version%3D1.0

Since the client-side signing logic is verified correct against a trusted reference library and the most common encoding bug is ruled out, I suspect one of:

• The Consumer Secret reset hasn't fully propagated on your servers yet (similar to the documented ~24h propagation delay for OAuth 2.0 IP whitelist changes)
• My application isn't yet approved/enabled for Signed and Delegated Requests (3-legged OAuth / Food Diary access), and the API returns a generic "Invalid signature" instead of a permissions-specific error

Could you please:

1. Check your server-side logs for requests from this Consumer Key around the time of this email, and let me know what signature mismatch (if any) is being detected
2. Confirm my application is fully approved for 3-legged OAuth / Delegated access to Profile — Food Diary endpoints
3. Confirm my current Consumer Secret is active and correctly propagated

Thank you for your help — happy to provide additional debug output (nonce/timestamp/full request) if useful.

[seba...@fatsecret.com]

Thanks for reaching out.

- It can take up to 24 hours for the change in secret to be live - while it usually is takes less than 1hr

- There is no additional permission setting for our team to provide access to 3leggedOAuth i.e. this API capability is enabled for all API keys by default

- Can you please try using Postman first?