Authorization header: tried curl and postman, used postman’s basic auth feature as well as generating token manually (base64 encoded clientId:clientSecret) with a different charsets - same.
I’ve tried to re-activate an application, regenerate the client secret, but nothing seems to work.
Is there anything I should check in order to fix the problem?
Could it be that there are no permissions to use the Server-to-server but somehow I’ve managed to create an app and generate credentials?
@maksym.rossiitsev can you share the exact request you’re making to generate the token manually? If you’ve confirmed the app is created and activated in our marketplace, it’s likely some syntax error in the request.
Not sure what is it exactly that I’m missing… (obscured the basic token and accountId for safety reasons).
Interestingly, if I’m using an incorrect token - I do receive a different error
@maksym.rossiitsev I think the encoding might the issue. Our example in the docs is more-so pseudocode rather than exact syntax. If you were to test out encoding on a site like this: https://www.base64encode.org/ → entering your clientId:clientSecret → retrieve the encoded value, and then paste that to your curl command like:
curl -X POST -H ‘Authorization: Basic <encoded_value>’ -d ‘grant_type=account_credentials&account_id=<account_id>’ “https://zoom.us/oauth/token”
It should work. Let me know if that works out for you!
Yes, this website is exactly the one I’ve been using for encoding the token…
Tried the option you have provided, but still no luck. And as I mentioned - it does acknowledge that I’m using wrong clientSecret when I do, but for some reason, whenever I’m using the correct one - it’s “Bad request” for me (even through the postman, with its Basic authentication method - it does encode it itself).
Is there anything service-activation related, that might be the reason of such behavior?
I have created an Oauth app today, so I was wondering it might require a little time to get up and running (had something similar with MS services), guess there shouldn’t be anything similar in Zoom, right?
@maksym.rossiitsev in the zoom app marketplace, did you create an OAuth app or Server-to-Server OAuth app? In this case we’d want to ensure you created a Server-to-Server app. Secondly, I have seen the case where someone creates an app in the marketplace, selects their scopes, gathers their credentials, but forgets to actually activate. Can you confirm that the Server-to-Server app is indeed activated? You should be able to see this in the Activation sidebar menu item of the app.
But yes once the app is activated, it should work immediately. I don’t think there’s much of a latency at all before you can start using it.
Yes, and yes - it is Server-to-server, and it is activated. The only thing is that it says “Intend to publish: no” and that the app is not listed on the marketplace (I believe this is how it should be, but just to make sure).
Another thing - there is a requirements block, and I’m not sure if it has anything to do with the problem.
I’m not a global administrator in the organization, so wonder if this could be related.
@maksym.rossiitsev as a final check, would you be willing to utilize this script we have available on our github? It’s a CLI tool for generating server-to-server oauth tokens. All you need handy is your client id, client secret, and account id.
If this still 400’s I think we can narrow down the issue to be account/role permission related.
Hi @brandon.abajelo
I have managed to make it work from the code, so it does seem like this could be an encoding issue (still doesn’t work from postman and curl, but that’s a different story I think)
