We have a native zoom app that a user can install, but when they are prompted to log in to our platform, some users are hitting the error:
zoom 403 Forbidden, domain or scheme is not allowed:
https://<external org>.okta.com/app/<external org><internal org>sso_1/<...>/sso/saml?SAMLRequest=<...>&RelayState=<...>
Our auth flow steps are:
id.<internal org>.io/sso/authorize
returns a 302 redirect with the location as the auth0 url for that sso org.- Auth0 returns 302 redirect with the external identity provider url for that org
- SAML request is sent to the identity provider url for that org. (We think the 403 error occurs here.)
Internally we use Okta as an identity provider and have had few issues logging in. However, for some of our external customers who also use Okta, the login may fail with the error above. We have included *.okta.com
in the domain allow list. Additionally we have many orgs that have unique identity providers and will need to be able to handle all of those cases too, as some of those users hit 403 forbidden errors too.
Troubleshooting steps we have taken:
We have worked with customers and have confirmed that the 403 forbidden errors aren’t being captured in the network logs but are clearly occurring based off of our app’s data dog logs. We are taking this to mean that because we are not even seeing the 403 coming in the network log, that the zoom client itself is rejecting the outbound network redirection.
Specifically we are needing help to solve two problems:
- Why are we getting the 403 errors? And why would it succeed for some but fail for others?
- How can we make sure the solution is scalable to orgs that have unique identity providers?