Data Compliance API - Deauthorization Endpoint URL

Hi Everyone,

I’m creating an APP for the marketplace, the scopes the application are the following:

  • View your meetings (meeting:read)
  • View your recordings (recording:read)

Looking the documentation about the data compliance and the deauthorization, I noticed the following:

Looking this information, I ended up with some questions:

  1. My application only have rights to read meetings and recordings, by saying this, to be specific, we only store the tokens, which are already encoded, we do not store any sensitive user information, so, this normative is going to be mandatory for us in order to have the application approval?

  2. Why do I need to retain information not related to my app purposes ?

Also, talking about the data Security and Compliance:

  1. How is going to be tested the information encrypted or hashed inside the database ?

Regards,

Karol Garcia,

Hi,

Please accept our apologies for the inconvenience caused. We found some bugs in the data compliance docs, and since we have hidden it.

I will respond here when we have updated it and its available to use.

Thanks.

We have been waiting on this for 24 days. Can we get an update? Karol is developing this application for us. We can not proceed unless this is addressed. Please advise.

Todd

Hi @tbryant,

Thank you for patiently waiting as our team is still working on resolving those bugs. I completely understand, how important this documentation is to your workflow and I can see how frustrating it would be.

Once again, I am sorry it is taking us this long to resolve the problem, and we look forward to provide a resolution earlier than this in the future.

As mentioned in the previous post, I will post on this thread, once the we update the documentation. If you want me to send you and email, regarding the resolution, please send a PM to me with your email address, and I will update you as soon as possible.

If you have any further questions or concerns, please let me know. I’m here to help!

Thanks,

Thank you for getting back to me. Do you have a timeline on this or a work around for now? Let me know.

Thanks,

Todd

Hi @tbryant,

Currently, we do not have a definite timeline, but I will update this thread as soon as we update the docs.

Apologies for the inconvenience caused.

Thanks,

Please let me know if there any option that can replace the Data Compliance API - Deauthorization Endpoint URL.

Thanks,

Todd

@tbryant, Unfortunately, there is no workaround for the Data Compliance API - Deauthorization Endpoint URL. But as mentioned, our Engineers are working diligently to resolve the issue, and I will update this thread, as soon as the issue is resolved.

Thanks,
Ojus

So if we use this method for OAuth, will our application be approved?

Please let me know.

@tbryant,

Currently, since our Data Compliance API & Deauthorization Endpoint URL are under development, we do not consider those as a criteria for approving an App.

If your application satisfies all the other criteria, your app should be approved. If your app is not approved, you will receive an email from the Marketplace team to about the updates that you would need to do to get your app approved.

Please let me know if you have any other questions.

Thanks,
Ojus

The Data Compliance API is live and documented here: https://marketplace.zoom.us/docs/guides/authorization/deauthorization

1 Like

Hello, thanks for putting up the Compliance API documentation!

I’ve notice two things wherein the documentation doesn’t line up with what’s observed:

1 - I see no authentication header in the Deauthorization Event Notification webhook POST (i.e. HTTP_CLIENTID, for example, is set, but HTTP_AUTHENTICATION is not). Indeed, my app’s Verification Token isn’t present anywhere in the payload.

2 - When posting a reply back to https://api.zoom.us/oauth/data/compliance (to report compliance_completed as described here) I am unable to get anything other than HTTP 400 in return, with a response payload of precisely the following:

{"reason":"Internal Error","error":"invalid_request"}

This might well be user error, but I have no clue as to what that error might be. The Basic Authentication I’m using is precisely as is working in calls to other API endpoints, and I’ve triple checked the POST data fields to match what is expected.

Given the provided reason of “Internal Error”, is this functionality perhaps not quite fully ready for use?

Hey @john, thanks for posting and using Zoom!

The Verification Token is present under {requestObject}.headers.authorization.

Here is an example in Node.js / Express.

Here is a working example of a request to the POST /oauth/data/compliance endpoint.

If these examples don’t help solve the issue, can you please post your request body here so I can debug (remove any sensitive information)?

Thanks,
Tommy

Hi Tommy,

Thanks! I still don’t see my app’s Verification Token: I’m working in PHP so I would expect to find it (I think!) in the incoming request’s headers (as obtained from PHP’s apache_request_headers() function, or directly in $_SERVER['HTTP_{uppercaseHeaderName}'], i.e. $_SERVER['HTTP_AUTHENTICATION'] in this case).

Even if I’m looking it up in the wrong way I would expect to see that token value present SOMEWHERE in the payload, but I don’t. Perhaps this is because my app is still not yet approved for the marketplace?

Nevertheless, I figure requiring a match on the client_id HTTP header (which is present as expected), plus all the other values that have to line up, enables my code to be pretty darn sure that the request originated from Zoom!

To the other issue, that Node.js example you gave me was super helpful: I see now that sending the 'Content-Type: application/json' header and sending the payload as JSON encoded is the key. (I had been doing form-based postings of the payload, which was wrong and presumably the cause of the “Internal Error” message.)

So on balance I’d say I’m good; thanks again for your help!

Cheers,
John

1 Like

Hey @john!

You are correct, you will only receive the Deauthorization Event Notification Webhook with the Production version of your app. You can test this by installing the production version of your app via your apps publishable URL,

54%20PM

And then uninstalling your app on your “Installed Apps” page.


I made a simple PHP web server and was able to see the Verification Token in the request headers (when testing a Zoom event/webhook sent to my server). Here is my code:

Example 1.

<?php

error_log(print_r($_SERVER, true))

?>

41%20PM

Example 2.

<?php

error_log(print_r(getallheaders(), true))

?>

Just FYI your client_id is publicly available via the install url. So I would use the Verification Token to verify the requests are coming from Zoom as the Verification Token is not publicly available.

Example:
https://zoom.us/oauth/authorize?response_type=code&client_id={YOUR_CLIENT_ID}&redirect_uri={https://YOUR_REDIRECT_URI}

Happy to hear you figured it out :slight_smile:

Let me know if you have any other questions!

Thanks,
Tommy

Hi Tommy,

Good insight about the client_id being publicly available!

Thanks to this from Stack Overflow I figured out why HTTP_AUTHORIZATION was missing from the $_SERVER variables. I just needed to add this to my htaccess file to make it appear:

SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0

I’m good to go, thanks again!
John

1 Like

Hey @john, happy your issue was resolved :slight_smile:

Apologies for not sharing my .htaccess file in my post above ^

Happy building!

-Tommy

1 Like

We are facing the same issue as raise by the OP.

Has there been an update to the endpoints/interfaces to allow applications that only need meeting related endpoints to be able to determine which account a deauthorization event notification refers to?

If not, does this mean the deauthorization event handling is not required for compliance?

Are there any plans to include the account_id along with the payload that returns the refresh token during the oAuth process? Doing so would allow us to store the account_id along with the credentials which would enable us to lookup the account referenced in a future deauthorization notification.

Hey @zeus,

Apologies for the late reply!

The Deauthorization endpoint is meant to notify your server when an app is uninstalled, after which you notify Zoom that you have cleared out any user data you may have retained.

If you do not retain any user data at all, you still have to notify us.

If you JWT parse (their are code libraries that do this) the access_token, you will see the account_id in the object. :slight_smile:

Let me know if you have any other questions!

Thanks,
Tommy