I am writing this post to seek guidance on how to implement in-client OAuth - I am experiencing an issue related to the
When using my development app with the relevant features and scopes enabled, and having installed the app, n the “Allow” splash screen always shows when invoking the
Here is a Loom video demonstrating the issue
A few specific questions:
- How can we use the
authorize API silently? (without triggering the “Allow” splash screen)
When I load my app, my user context has status
'authorized', but the splash screen still shows when triggering
Is this a bug? Or, is this something that behaves differently in development apps?
I can’t seem to get the
onAuthorized event to be sent, because the splash screen always shows on my development app when I trigger the
authorize API, despite being in
- When a user installs the app from within the client, what is the ideal flow for using
I modelled off the Advanced React Sample App, but still finding it very confusing.
After a user has clicked “Add” and then “Allow” from the Marketplace in the client, the app will load. Should we then do the following?
- (User clicks “Allow” in the Zoom client to install our app)
- Our app begins to load
- Our app notices we do not have a user stored yet for this user ID, so;
- Our app invokes the
- Our app waits for an
- We receive the event, submit the
code to our server and handle retrieving an access & refresh token
- Our server the uses this new access token to retrieve the user and other relevant data from the Zoom REST API
- Our server returns this data and the access token to our Zoom app
- Our app finishes loading
Any guidance would be much appreciated
We’re facing something similar. After showing the authorize prompt and the user accepting it, we then call the authorize API, again it shows the “Allow screen”, the authorize endpoint responds successfully and when calling zoomSdk.authorize the app just dies and restarts and keeps showing the “Allow screen” everytime we try to authorize and proceeds to restart itself(browser inspector closes and the panel goes to blank, opens the app again).
Update: Refined my post and updated the video.
If you’ve already authorized your app, you can refresh your token via:
/oauth/token endpoint (OAuth with Zoom)
You can store the access token on the backend against the zoom user id, so they can retrieve it when the user visits, via the zoom user id in the x-zoom-app-context
Thanks @ash.provost , we do that today for existing users that authorize from the web. I’m currently trying to figure out how to do the same for new users installing from the client
The problem I’m encountering at the moment is that when a user installs in the client (so, they’ve now authorized our app), the app loads and we don’t yet have an access or refresh token. We notice this, and so invoke
authorize(), but it shows the “Allow” screen. I expected it to be a non-interactive OAuth flow, completely invisible to the user as outlined here
Would you be able to help by breaking down the steps for authorizing the in the client? Specifically, when should we call the
Hey @ash.provost , just wanted to follow up on this – any ideas why calling
authorize() does not start a non-interactive OAuth flow in my development app?
We will raise this to our team to see if its a bug
The bug was on our end;
When calling POST https://zoom.us/oauth/token (from the docs here)
We were using the wrong
redirect_uri value in the request body.
We are now using our front-end web application’s URL when doing in-client OAuth, instead of redirecting to our back-end auth URL (as we do when a user installs from the browser).
Thank you for keeping us posted!