Suddenly some users have started reporting that they cannot authenticate with Zoom anymore using our app - they see an “Invalid Scope” error. Any idea what’s going on?
Here’s the request URL that results in this error:
We’re using AppAuth to handle OAuth for us. AppAuth adds scopes with a space in between each scope - could that be causing this issue? Why has this suddenly come up?
Or could it be the “email” scope triggering this? This seems to be the default OAuth scope that gets added.
Hey,
I’m joining Fahad on that, as a user reported me the same issue on my app wappointment.com
At first I thought the user had a different Zoom account as I couldnt reproduce the issue. And I actually managed to reproduce the issue later. I’m not sure what exactly is causing the issue, but this is what I found out.
When I’m logged in to Zoom to start with and I begin the authorization process by clicking the Zoom Sign in button : Create Free Account
I will get that Invalid Scope error, with those scope parameter appearing in the url &scope=user,meeting . If I remove the scope parameters from the url the invalid scope issue will disappear.
Now if I go through the same process being logged out of Zoom, the issue will not happen and the authorization process will go through.
Not sure if the issue is in my implementation of the OAuth or if it’s a Zoom issue.
Anyway I keep you posted if I find out something else.
We are now seeing an increasing number of users report this. One user wrote:
This only seems to happen when I am already logged into my Zoom account in the web browser (which ususally is the case. When I explicit log out from my Zoom account, the authorization works. So problem solved. But it may be a good idea to fix that behavior for users who are already logged in, which is probably not a rare thing.
Hi @fahad.beehive,
Thanks for reaching out about this—I can see you’ve written in via email so I will reply back to you there.
Thanks,
Will
I can confirm that we are also having this problem as of the past week. First reports came in June 15th and we received more today. Please follow up with us to help get this resolved.
Hi @ezra,
Can you please share a recent example with us directly at developersupport@zoom.us so that we can further investigate? Please share the exact URL that was used to authorize and the email or user ID of an example user that ran into the invalid scope error.
Thank you,
Will
We encountered this very issue. It looks like sometime in the past week Zoom started rejecting any auth URLs with scopes in them. You need to not pass the scope parameter, and let your marketplace app define the scopes.
If that is true, what worries me is that this behavior is undocumented and unlike any other OAuth implementation, and so if they later revert and require scope to be passed, our changes will break our apps again.
We need a concrete, documented response for this. It’s bad enough that zoom just broke our current and previous versions of our apps.
Zoom - this kind of a change is frankly unacceptable. Most of us use open source libraries that handle OAuth in a standardized way, where it’s near impossible to make such changes without changing the code within the library.
@jimig and @fahad.beehive,
Thank you for sharing this feedback with us—I’m currently in the process of confirming this concretely with our Engineering team, but this should be the case as @jimig described it.
While Zoom never explicitly supported including app scopes as part of the authorization URL, this was previously ignored in the case that they were included. However, as part of our ongoing commitment of prioritizing security, a recent enhancement was made that will now consider scopes added directly to the authorization URL to be considered invalid. You will need to omit the scope parameter from your URL and let your OAuth Marketplace App handle the scopes for your integration.
Having said this, I completely understand the headache this can cause if you were previously passing the scopes in the auth URL and not seeing any issues with this until recently.
I’ve raised this with our Engineering team and am actively sharing this feedback with them to make sure changes like this are better announced in the future.
Thank you,
Will
Thanks Will, yea any breaking changes always good to learn about in advance! We lost hours digging into this, and customer’s were unable to connect Zoom for 2 days.
This really has nothing to do with security, it would be trivial to compare the list of scopes passed in through the URL to the list of validated scopes associated with the client. In fact I’d argue this creates a less secure environment because now clients can’t request a subset of the scopes their app is authorized for in scenarios where all authorized scopes aren’t needed.
2 Likes
Thank you for the feedback @Jared_Morse — I appreciate the point you’re making, and have shared this feedback with our team.
Best,
Will
Hey Will,
Thanks for the feedback, actually it makes complete sense.
And basically the issue was(in our case) due to the way we had implemented OAuth. We were using a boilerplate for OAuth with Laravel Socialite and by default the scope parameters were sent back to the auth URL.
While it makes sense for most 3rd party implementation to send these scope parameters, it doesn’t with Zoom were scopes are specified already at App level.
I consider this a non issue.
Cheers,
Ben
This is how OAuth works - this is not a non-issue by the way. As Jared pointed out, this goes against OAuth and “Security” in general since you want to be able to authenticate with fewer scopes at times when the default ones that apply to you aren’t needed. For instance, you may simply wish to obtain read-only / profile info for a companion app that does nothing other than display your existing meetings, whereas you would want your default scopes requested by the main app.
Either way, you’ve only re-iterated my point; most of us rely on 3rd party OAuth libraries that handle all of this transparently for us. Changing their code or customizing such behavior at times isn’t always possible without tinkering with forked code.
I consider this a bug, in addition to other known issues with authentication in general (such as not being able to authenticate multiple devices for the same account without being booted from the rest).
How difficult would it be for zoom to simply ignore and not process passed-in scopes for “security” rather than rejecting authentication entirely and labeling it as an “Invalid Scope”?
Allow me to assist the developers if this seems difficult:
var paramsToParse = params.filter { $0 != "scope" }
...
A line of code and it should automagically become non-breaking. Bonus for fixing the invalidation of tokens bug:
if (authenticated()) {
// existingTokens.invalidate()
}
A +1 from us on this too. We explicitly request scopes in the query string in the authorize call so that Zoom grants the minimum permissions required for the options the user has selected when connecting. This is a basic infosec principle - the principle of least privilege.
If this “improvement” remains, we’ll have to set up multiple OAuth clients with different scopes (e.g. at minimum read-only and read-write), and then request the relevant OAuth client depending on what permissions the user needed.
Not only is this likely to mean coarser permissions (less secure but better than requesting write permissions when the user just needs read) but it’s also going to be an additional burden for you guys at Zoom if we resubmit our app for approval: the Zoom team who check apps will need to check at least 2 or maybe 3 versions of the same app.
Thank you for sharing this feedback @richard.kirby — we appreciate it, and I will be sure this makes it to our team.
A +1 from us on this as well. Makes things really inconvenient to have an App for each subset of scopes. (This number increases exponentially!)
Even if that were the case, the change could have been made in a non-intrusive format where the parameter was ignored from the URL. (This is permitted as per the standard OAuth flow)
I looked through the changelog, I don’t see any updates warning developers of this change. Am I looking at the right source?
Also just an FYI - I think the scope parameter still works for a single scope - but fails if there are multiple scopes passed to it.
Thank you for the feedback—we are working on communicating changes like this better in the future, and we value the insight from our developer community.
1 Like