Deauthorization endpoint and expectation

Description

We are planning to start the process of publishing our application to Zoom marketplace. We are developing an application which will be using account based OAuth flow. We are not going to be using per user based authentication flow and so we do not store any user information. Below are the two things that we store in our database:

  • Refresh token provided by Zoom for each of our customer who authenticates using OAuth flow.
  • Meeting ID of meeting created using the meeting APIs. This meeting id will be used in future to get fetch more details about the meeting. In our flow, our end users do not go to Zoom UI and the entire meeting creation flow happens via API. Once the meeting is created, we fetch the meeting details and share it with user in the email that is sent out from our system.

Below are the questions that we had:

  1. Since we are not storing any user information and our application is using account based OAuth flow, what data should we delete? Should we be deleting all the meeting ids from our database for that customer? Do we even need to do anything if we are not storing any user data in our database? The only data we have is meeting id and the details of the meeting that is sent in the email to the end user.
  2. We looked at the payload of the de-authorization endpoint and it contains fields like account_id, and user_id. But we do not store this information in our database. So how do we identify which account is this de-authorization request for? While searching on the forum, we came across below topic in which the user has posted similar issue. The solution is to decode the access token while authorization process is going on and fetch the account_id from it. Is this still a suggested approach or is there a better way? We do not want to increase scopes for our API.
  3. What happens if zoom never receives our data compliance request due to an issue? Should we retry?
  4. What happens if we never receive deauthorization request from Zoom even if customer has uninstalled our app?

https://devforum.zoom.us/t/deauthorization-endpoint-user-identification/33047/7

Which App Type (OAuth / Chatbot / JWT / Webhook)?
Account Based OAuth

Which Endpoint/s?
Data compliance: https://marketplace.zoom.us/docs/guides/publishing/data-compliance

Hi @bhavik.bhagat,

Thanks for reaching out about this. Please see my post here and let me know if this helps to clarify the expectation:

Thanks,
Will

Hi,
thanks for sharing this guide, finally I understand about the Deauthorization endpoint and expectation to set at my site. and for Will, I will check your post
thanks
best regards

Thanks for the details on what data to remove. For clarity, in the situation where messages stored in the system might contain zoom meeting info, do we have to remove that meeting info from the messages as well?

As for point 2, is the approach mentioned in https://devforum.zoom.us/t/deauthorization-endpoint-user-identification/33047/7 still suggested for our situation?

Also in the case there is any problem with the deauthorization call reaching us, is there any retry logic on Zoom’s end? Do you have any recommendations on retry logic, like how often we should retry to send the confirmation if there is a problem on our end?

Glad I could help clarify, @gunturhakim22! :slight_smile:

@bhavik.bhagat Good questions, happy to clarify.

First, regarding:

in the situation where messages stored in the system might contain zoom meeting info, do we have to remove that meeting info from the messages as well?

Yes, any Zoom info related to the user or account in question that is stored on your end should be removed as part of compliance.

As for:

As for point 2, is the approach mentioned in Deauthorization endpoint user identification - #7 by dave2 still suggested for our situation?

Yes, this is still a valid method for determining user/account.

Lastly:

Also in the case there is any problem with the deauthorization call reaching us, is there any retry logic on Zoom’s end? Do you have any recommendations on retry logic, like how often we should retry to send the confirmation if there is a problem on our end?

Zoom will try to deliver the deauthorization notification up to three times . The first retry will be sent 5 minutes after the initial notification delivery attempt, second retry will be sent 20 minutes after the first retry attempt and third retry will be sent 60 minutes after the second retry attempt for an event. If a 2XX response is received after one of these attempted retries, the deauthorization notification will continue to be sent as usual. However, if Zoom doesn’t receive a 2XX response even after executing all three retries, no further notifications related to that event will be sent to your app’s deauthorization endpoint.

We recommend utilizing a monitoring service to ensure the health of your endpoints. Should you ever suspect that perhaps your endpoint failed, you’re welcome to reach out to us directly to help confirm/troubleshoot.

Let me know if this helps. :slight_smile:

Best,
Will

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.