Get token from 2 accounts: the first works fine, the second gives error 400 "Invalid client_id or client_secret"

[Sciabal (Marco)]

I have 2 Zoom accounts and I use a function to get access token.
For the first account the function works fine, I get the token and make API calls.
For the second account I receive the error 400 - “Invalid client_id or client_secret”.

I created the same Server-to-Server OAuth app on the 2 accounts, with the same scopes. I also checked several time all the accounts’ parameters (AccountId, ClientId, ClientSecret, etc.) and they are correct for both accounts.
The script has no errors and works fine with the first account.

Here my steps:

endpoint:
https://zoom.us/oauth/token?grant_type=account_credentials&account_id=AccountID

Authorization
Basic

Authorization Data
Encoding Base64(ClientID:ClientSecret) → encoding also checked with different tools

First account response:
200
{“access_token”:“token”,“token_type”:“bearer”,“expires_in”:3600,“scope”:“user:write:admin user:read:admin meeting:read:admin:sip_dialing meeting:read:admin user:master meeting:write:admin”}

Second account response:
Error 400
{“reason”:“Invalid client_id or client_secret”,“error”:“invalid_client”}

I can’t understand the reason of these 2 different behaviours. The 2 accounts are configured identically but switching the function from first to second it gives the error.

The only difference I can see between the 2 cases is that the result of Base64 encoding for the second accounts generates a string with a space inside:

Base64 data account1 = […]4MUp4
Base64 data account2 = […]FZR Sw== ← space between R and S

Can this be a problem?

Some suggestions?

[MultiplayerSession (Christopher Lee)]

Please check the Base64 encoding mechanism you’re using, or post the source code that does it. Base64 encoding should not produce whitespace except to impose line length limitations, which should not be used for API calls.

[Sciabal (Marco)]

Yes, you are right!!
In fact, the “white space” is not what it seems. After hours I discovered that it is an ASCII character with code 32. Probably my encoder script generates it in case of specific combination of ClientID & ClientSecret string.

At the end: I’m not able to intercept the strange character with Classic ASP so I decided do use directly the Base64 string saved in the database.
It worked.

Thanks for your support!