Hello wonderful Zoom folks!
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?
And a big question:
- What are the benefits to publishing?