Trouble using in-client OAuth silently (`authorize` API)

Zoom Apps
1

Hey all,

I am writing this post to seek guidance on how to implement in-client OAuth - I am experiencing an issue related to the authorize() API.

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 authorize() API.

Here is a Loom video demonstrating the issue

A few specific questions:

  1. 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 authorize().

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 state: 'authorized'

  1. When a user installs the app from within the client, what is the ideal flow for using authorize and onAuthorized?

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?

  1. (User clicks “Allow” in the Zoom client to install our app)
  2. Our app begins to load
  3. Our app notices we do not have a user stored yet for this user ID, so;
  4. Our app invokes the authorize API
  5. Our app waits for an onAuthorized event
  6. We receive the event, submit the code to our server and handle retrieving an access & refresh token
  7. Our server the uses this new access token to retrieve the user and other relevant data from the Zoom REST API
  8. Our server returns this data and the access token to our Zoom app
  9. Our app finishes loading

Any guidance would be much appreciated

2

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).

3

Update: Refined my post and updated the video.

4

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

5

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 authorize() API?

6

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?

7

We will raise this to our team to see if its a bug

8

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).

1 Like
9

Thank you for keeping us posted!