we have an app on Zoom marketplace (Learnupon) with the following requirements for authorising the app → App Marketplace . These permissions translate to meeting:write:admin, report:read:admin, user:read:admin and webinar:read:admin.
Up until ~30 days (that’s a rough estimation), if the Zoom account owner authorised the LearnUpon app (Account lvl app) to be installed, Users that were not Admins were able to authorise and complete the process of oAuth. Right now, unless these permissions are granted to the User:
Sooo, my question is has something changed on the OAuth/Authorisation process? And what can we do about it? Is it a bug?
We have a couple of Customers coming at us because they used to be able to do this, and now they can’t . They don’t want to grant these changes to their Instructors, but also need to integrate. I’ve looked at the blog and this forum, and don’t see anything about this issue, anything you can help with would be much appreciated.
The error the user receives when installing the app is:
“An account admin is required to install this type of app. Please contact your account admin or IT administrator to install this app.” covered in scenario two in your previously attached link.
To Siniša’ point, until recently, if a Zoom account owner authorised the LearnUpon app (Account lvl app) to be installed, then Zoom users that were not Admins were able to authorise and complete the process of oAuth.
This no longer seems possible as Zoom is requiring any connecting account to be admin level with the permissions listed here: App Marketplace
The access permissions displayed in the market place also seem to be incorrect.
In testing, we have noticed that view and edit permissons are required for most fields, effectively demonstarting that only admins are now able to connect through oAUTH which wasn’t previoulsy the case as mentioned above. Has there been any recent changes to permissions required by Zoom?
I believe there is a misunderstanding here. Since it is an account level app, it can only be installed once per company Zoom account, it does not need to be installed for every Zoom user on the company account.
Thank you for taking time to look into our question. We took some time to test our integration and speak to Customers about what they were experiencing. The confusion seems to be coming from permissions around Users.
If you look at my first post in the thread, scope listed on the app for Users is just user:read:admin, which up until recently meant just view permissions. Right now, Customers are unable to authenticate with the app unless they grant edit permissions to the User (if you look at the image bellow, both checkboxes need to be marked) in order to complete the oAuth process.
Just to confirm, the app (which is an Account lvl app) is installed and approved by account owner. If we were to create a new User on the Account and not grant him Users edit permission he would not be able to complete oAuth. Since there are other users in the account using the integration, and as you said account lvl apps only need to be installed once, we think the wording in the image David posted above is just referencing installation by mistake, guess it’s a generic message for everyone trying to oAuth.
So it all boils down to user:read:admin, is Users edit permission requirement for oAuth a bug on Zooms side or can you give us any explanation of what is actually happening?
If you grant the user read and edit permissions, the error goes away and the account can be linked.
After the account is linked, you are then able to remove the Users - View & Edit permissions in Zoom right away, without any immediately-apparent issues.
After which, a user can disconnect and reconnect their account that has just the view permission and there are no errors. I’d be glad to setup screenshare via Zoom to show you this in action, or perhaps provide a video if you can provide a secure place for me to send it.
After the initial link of the users account has been made, you are then able to remove the Users - View & Edit permissions immediately after, without any immediately-apparent issues, leaving just the view permission in place.
The user can then disconnect and reconnect with just the view permission going forward. So it seems edit is always required in the first instance when it shouldn’t be according to the Zoom permissions page.
I’d be happy to setup a screenshare via Zoom, or provide a video showing this behaviour if you’re able to provide a secure link as I do think there is a bug here that needs to be invetigated further.
In order for us to take a closer look, can I kindly ask that you share these details and the user ID of the users in these examples with us directly at developersupport@zoom.us? This will help us to verify their settings and better understand if there might be something more going on here or not.
