We are getting ready to roll out our Zoom system integration to our clients, where they are able to set up and configure their own Zoom OAuth APIs for their organizations and have it work seamlessly in our software.
Right now the system works perfect in a Dev environment. By perfect I mean the restrictions and visibility of the OAuth App in Dev is exactly what is desired.
Users are allowed to authenticate only if they have been added as a user in the same organization.
The OAuth App is not publicly listed, as there is never a need to access the Marketplace to download anything in order to use the integration in our software.
As a completely made up example, Benford School District will use our integration. They set up their OAuth App in Dev. When they want teachers to be able to use the integration, they add that teacher to the same organization that holds the OAuth App. The teacher can then meet with their students using the integration. No one outside of district employees will be able to authenticate, which is desired. With this setup, visibility in the Marketplace is not needed.
When we set up these OAuth APIs in our QA environment to simulate a client school district, we have to mark them as Intend to Publish to Marketplace in order to get feature #1. If we do not select that “Intent” no user except the API owner is allowed to authenticate into the OAuth App. So we do have to mark with “Intent”, even if there is no benefit to publishing to the Marketplace.
With all that stated, some questions!
If an OAuth API is published, can we retain the limit on who can authenticate to users in the same organization?
Can we just never publish, and continue to run in this in Dev since it is the ideal ruleset?
Alternatively, can the ability to authenticate be added to users in the same organization for OAuth APIs that will not be published?
I suggest publishing your app on the marketplace for the following reasons:
It is much easier for your users / customers to just click “Install” rather than setting up an entire OAuth app on the marketplace. This will also reduce the support load on your end.
You can get exposure to your business with the traffic going to the marketplace.
You can have your app be published, but still limit who can install it by using the “Visit site to install” option.
Unfortunately we can’t publish a single app that all of our clients can use. We provide the integration within our software, which they install. They are responsible for the management of their Zoom accounts. School districts tend to not like giving up the reigns of control.
At the school district level, it is not easier for them to click Install from the marketplace. Install happens on-demand when creating or joining meetings. School districts would also not be concerned about business exposure.
The “Visit site to install” option also does not restrict who can install. If it allows someone who is not a member of the organization to authenticate into the OAuth API, it is a security issue.
As an example, a single teacher has an @gmail.com Zoom account for personal use. However, the school district does not want the teacher using that account for school business. But they do have an @district.edu Zoom account that the district has approved and is part of the organization. If the teacher then leaves the school district, that account can be removed from the organization, effectively removing the teacher’s access to the OAuth App, which is desired.
This brings me back to my first three questions!
If an OAuth API is published, can we retain the limit on who can authenticate to users in the same organization?
The answer to this one, based on your response, appears to be No.
Can we just never publish, and continue to run in this in Dev since it is the ideal ruleset?
By We, I mean our individual district clients who have their own OAuth APIs and use our integration.
Alternatively, can the ability to authenticate be added to users in the same organization for OAuth APIs that will not be published?
