OAuth2.0 for server-to-server (cont)

[Ruslan]

Using this template helps us debug your issues more effectively

Description
I’m trying to use OAuth backend client flow, token is generated ok using client_credentials but is unusable (not associated with user account hence cannot inherit scope).

Error
Using client_credentials OAuth2.0 flow generates error
{'code': 2031, 'message': 'Zoom Phone has not been enabled for this account.'}

Which App Type (OAuth / Chatbot / JWT / Webhook)?
OAuth2.0, account-wide

Which Endpoint/s?
/phone/*

How To Reproduce (If applicable)
Steps to reproduce the behavior:

1. Request Token using client_credentials
2. Use token for any API call
3. See error

Screenshots (If applicable)

{'access_token': 'very.long.token',
 'expires_at': 1623061684.7239587,
 'expires_in': 3600,
 'scope': ['phone:read:admin'],
 'token_type': 'bearer'}
{'code': 2031, 'message': 'Zoom Phone has not been enabled for this account.'}

Additional context

1. I know that API docs officially only mention authorized_code OAuth type. However authz code is an interactive flow, it requires user interaction, request authorisation, etc. Hence this flow is not suitable for backend (server-to-server) auth.
2. In the similar thread it was suggested to use an exploit to somehow dump generated token from app code, store it and its refresh token, and then periodically use token refresh process. Now this approach is a bit cumbersome as you need to code in interface to interact with user and then store the tokens into persistent storage which will be refreshed. However if app is executed in secure environment with any credentials being stored/retrieved from the crypto vault - this approach is not an easy task to achieve (you cannot really interact with the app, it is driven by external scheduler which unlocks the safe for credentials. In other words a no-go.
3. on the other hand the client_creds type is exactly designed for this type of integration. Moreover token is successfully generated, just is not usable (is not associated with any entitled account) even though the scopes are negotiated properly.
4. JWT is a no-go because it breaches least-privilege model.

So do I understand it right and under given restrictions it is impossible to use Zoom API (because of lacking non-interactive token with granular permission control)?

[will.zoom (Will)]

Hi @Ruslan,

Thanks for reaching out about this, and good question.

I can confirm that, at this time, JWT Authorization is the only supported method for handling server-to-server requests. You’re correct that our OAuth Flow as it stands currently requires end user interaction/authorization.

Having said this, we are working on expanding our OAuth flow capabilities, and a server to server solution for OAuth is on our near term roadmap. We hope to have more updates to share on this front soon—in the meantime, we recommend subscribing to our Changelog to keep up with the latest developments and announcements.

Thanks,
Will