We have a custom integration that use OAuth and it redirects the user to https://zoom.us/oauth/authorize. One customer has an issue. They get an error “This site can’t be reached” with the URL “Sign In - Zoom…” shown in the error message. They found that if they change the URL in the browser to “https://companyvanityprefixzoom.us/signin?.…” and reload; it works and they can complete the oauth sequence.
We have a vanity URL with our Zoom instance and do not get this behavior. I’m wondering if it is because login without the vanity URL, is disabled by this customer but not us. Or perhaps they have login without SSO disabled. Anyone have any ideas?
As an experiment, in our dev instance, I tried our oauth sequence with both https://zoom.us/oauth/authorize and https://ourcompanyvanityprefix.zoom.us/oauth/authorize.
Both worked. The former prompts me for user and password if I’m not logged into Zoom. The later always takes me to our SSO facility so can only login as me. (For testing, we often use several different Zoom users which is why the username/password login is useful.)
So I’m wondering, could this customer have non-SSO login disabled and therefore, it only lets them login with the vanity URL.
We don’t generate the signin URL in the error message. We redirect to the oauth URL and zoom redirects to signin. So I’m wondering if we were to initially ask for https://companyvanityprefix.zoom.us/oauth/authorize instead of https://zoom.us/oauth/authorize, would it resolve the issue. If that is the solution, we could add a feature to add the vanity prefix to the oauth URL.