Testing OAuth app on multiple environments

[iwo.m]

Hello,

Description
I’ve already published my app to Zoom marketplace. The app production redirect uri is pointing to my production environment (abc.example.com) and it is working perfectly well. Now, I would like to add other features to my abc webapp and be able to test the integration with Zoom on pre-production environments. The environments are: env1.abc.other-domain.com, env2.abc.other-domain.com and env3.abc.yet-another-domain.com. I would also like to be able to connect multiple Zoom accounts on these environments (not only the account which created the app).

Since it is not possible to add multiple production redirect uris I can not authorize with the production app from pre-production environments. I also can not use any pattern in development redirect uri because my pre-production environments do not share the same domain.

How can I tackle this problem?

Which App?

App Marketplace

[iwo.m]

PS:
I noticed that “redirect URL” validation is behaving different than it was before my app publication (Step 2 from https://marketplace.zoom.us/docs/guides/auth/oauth). My requests used to fail with 400 when redirect URL sent by my app did not match the redirect URL placed in Oauth App configuration. Now these requests are correct:

Redirect URL sent from my app in Step 2: env1.abc.other-domain.com
Redirect URL in Oauth App config: abc.example.com

1. Is this behavior desired?
2. Is it safe to omit redirect URL parameter when performing Step 2?

[tommy]

Hey @iwo.m,

Great questions!

@iwo.m

Redirect URL in Oauth App config: abc.example.com

The redirect URL in the OAuth app config in the marketplace settings is the default one when someone clicks the “Install” button to install your app from the marketplace.

You can add multiple redirect urls, and set them dynamically by navigating the user to the authorize/install link yourself, like a button on your site. Checkout the dynamic redirect url docs here:

OAuth 2.0 - Authorization - Documentation

As long as the base domain is whitelisted, you will be able to set the redirect in step 1 of the OAuth docs.

Due note, since your app is published, these changes will only take affect on the development environment. Once your app update is approved, the changes will take place on the production environment.

Thanks,
Tommy

[iwo.m]

Hi @tommy, thanks for the response.

If I understood correctly, in Step 1 & 2 I can use multiple redirect_uri values as long as all the domains are listed here, in "Whitelist URL’:

It means that I could set up my production app with the following configuration and authorization flow would work fine on every environment on the list:

Redirect URL for OAuth: https://abc.example.com/oauth/zoom
Whitelist[0]: https://env1.abc.other-domain.com/oauth/zoom
Whitelist[1]: https://env2.abc.other-domain.com/oauth/zoom
Whitelist[2]: https://env3.abc.yet-another-domain.com/oauth/zoom
Whitelist[3]: https://abc.example.com/oauth/zoom

I am using “Direct landing URL” option to allow users to install the Oauth App, so it seems that “Redirect URL for Oauth” field is not really important for my use case (please correct me if I am mistaken anywhere here).

So coming back to the point I was trying to state - is it considered a good practise to integrate all non-production client environments with already published, live Zoom Oauth App. If not, then do you recommend any other pattern to achieve just that?

Thank you,
Iwo

[tommy]

Hey @iwo.m,

@iwo.m

If I understood correctly, in Step 1 & 2 I can use multiple redirect_uri values as long as all the domains are listed here, in "Whitelist URL’:

Correct! Just make sure that you use the same redirect_uri for Step 1. and Step 2.

For example, if for Step 1. one you use https://env1.abc.other-domain.com/oauth/zoom but then in Step 2. you use https://env3.abc.yet-another-domain.com/oauth/zoom it will fail. They need to be consistent throughout each instance of the OAuth process. Make sense?

@iwo.m

I am using “Direct landing URL” option to allow users to install the Oauth App, so it seems that “Redirect URL for Oauth” field is not really important for my use case (please correct me if I am mistaken anywhere here).

You nailed it!

@iwo.m

So coming back to the point I was trying to state - is it considered a good practise to integrate all non-production client environments with already published, live Zoom Oauth App. If not, then do you recommend any other pattern to achieve just that?

Yes, because you can use the Development Environment of your app to test them without affecting your Published Production Environment. I have seen some developers create two seperate apps, one for each environment, but to me that seems harder to manage. In the end, it is really up to you and what you prefer.

Thanks,
Tommy

[iwo.m]

Thanks @tommy, it’s getting much clearer.

Yes, because you can use the Development Environment of your app to test them without affecting your Published Production Environment

Actually, it seems that my development client_id is not working from non-prod environemnt, even if I am logged in Zoom on app developer account:

I would expect that development credentials allow the owner to authorize. I whitelisted all my environments and production credentials work fine. What can be wrong here?

Moreover, even if I were able to authorize with development credentials, then the authorization would only be possible inside the developer’s account, right? If yes, then how could I bypass this limitation so that every member of my QA team is able to test it freely on other accounts?

We have use cases where we need two or more distinct users (with distinct Zoom accounts) to interact, and these scenarios have to be performed on non-prod environments. I used to request for “sharing this app outside of the account” in “Submit” section but this option is no longer available after the publishing.

Thank you,
Iwo

[tommy]

Hey @iwo.m,

@iwo.m

I would expect that development credentials allow the owner to authorize. I whitelisted all my environments and production credentials work fine. What can be wrong here?

This error is thrown when a user outside the account is trying to install a non Published App. Double check the user trying to install the app is logged into the correct account.

@iwo.m

Moreover, even if I were able to authorize with development credentials, then the authorization would only be possible inside the developer’s account, right? If yes, then how could I bypass this limitation so that every member of my QA team is able to test it freely on other accounts?

Correct, however, if your QA team are users on your Zoom account, they will will be able to install and test the app.

Managing users

@iwo.m

We have use cases where we need two or more distinct users (with distinct Zoom accounts) to interact, and these scenarios have to be performed on non-prod environments. I used to request for “sharing this app outside of the account” in “Submit” section but this option is no longer available after the publishing.

Great question, let me talk to the team about this.

Thanks,
Tommy

[iwo.m]

Hi @tommy

This error is thrown when a user outside the account is trying to install a non Published App. Double check the user trying to install the app is logged into the correct account.

I double checked that - when redirected to Zoom authorization page from my non-prod environment, I am logging in on Zoom app owner credentials. client_id in redirect query param is equal to my “development” client_id from Zoom Oauth app configuration. The error is still displayed and I can not authorize.

However, when I take the “Publishable URL” (with “production” client_id embedded in it) I see the expected authorization prompt, my logo and scopes.

Correct, however, if your QA team are users on your Zoom account, they will will be able to install and test the app.

Unfortunately, “User Management” section is not displayed in my account settings. The type of the account is “Enterprise”, and it’s role is “Developer”. It seems that this account is a part of our enterprise program.

The issue is blocking further integration with Zoom. Do I have any options other than using “production” Oauth credentials for non-prod environments? It seems that it is the only way now to satisfy all the requirements stated above.

Thank you,
Iwo

[tommy]

Hey @iwo.m,

This will be easier to resolve over a Zoom meeting. I will send you the meeting details.

Thanks,
Tommy

[tommy]

Hey @iwo.m,

Our engineering team is investigating the root cause of this. (ZOOM-226260)

I will get back to you with an update as soon as possible.

Thanks,
Tommy

[iwo.m]

Thank you @tommy, waiting to hear back from you

Iwo

[tommy]

Hey @iwo.m,

We found the issue. It looks like the app was built on a personal/different Zoom account, and then that account was moved onto your company Zoom account. We will update the account for the app so it is fully configured. That will fix the issue.

Thanks,
Tommy

[tommy]

Hey @iwo.m,

You should be able to install the app now.

Thanks,
Tommy