Hello,
I am developing an application that uses OAuth to obtain access tokens and refresh tokens from users in order to retrieve recordings and transcripts. The users belong to Company A, and the application is intended to be developed by Company B (as data processing needs to be performed by Company B).
I have the following questions:
If this implementation is carried out, I believe it will be necessary to store Company A’s access tokens and refresh tokens in Company B’s storage. Would this violate Zoom’s terms of service?
If this does not constitute a violation, could you please share best practices for securely managing tokens while maintaining confidentiality?
I am struggling to find a secure way to manage access tokens and refresh tokens.
If there is a method to retrieve recordings and transcripts without using OAuth or access/refresh tokens, that would also be acceptable. I would greatly appreciate your guidance on this.
I apologize for the basic nature of these questions, and thank you in advance for your assistance.
Welcome to the community.
You need to think about the difference between the dev setup and if you publish.
When published you will have secret tokens in the app.
When company a want to use the app they will then get their access and refresh token
Company B will get a different access and refresh
Indeed multiple users will all get different access and refresh tokens.
So, the issue of storage. You need to provide App storage.
The most simple answer is to store them in cookies. I often keep my access token in a cookie, it is on the users machine and expires minutes. If you do this then it is good practice to encrypt them.
However, when it comes to the refresh token, I store that in my app database, it is encrypted and tied to the user id (also encrypted).
So for dev, I leave both as cookies, but once I am looking for production, the refresh will do in a secure database. One entry for every user all access and refresh tokens are different for each user and company
Thank you for your response.
I’m a little confused, so let me organize my thoughts using a diagram.
I have two questions:
I assumed that the access token would be stored in Company B’s storage during user authentication. In this case, the expected flow is:
Company A hosts a meeting on Zoom,
After the meeting ends, a webhook is used to send the download URL and download token to Company B,
Company B uses the information from step 2 to download the recording and transcript.
Does “keep my access token in a cookie” mean that the access token is retained on Company A’s side? Since Company A only hosts the meeting, I find it hard to imagine the access token being stored in the browser.
Looking at this link, it seems that access tokens and refresh tokens are not directly required for obtaining recordings and transcripts. Is that correct?
I can not answer this question because you need to look up a level first.
Are you going to publish your app to the marketplace?
Who is going to host the application?
If you publish to the marketplace, then each business user will authorize the application for their use, and it will be running on your hosted server with your hosted databases.
You will have the secret keys in within your application
Company A, B and any other will get their tokens when they authorise the app. But you will store any data on YOUR server, because that is the where the app and server is.
Otherwise, you are providing the app to be installed by each company. They will provide their own hosting and database and will create their own entry in the Zoom marketplace for their own personal use and probably run forever in development mode as they don’t need access for anyone else.
Storing Company A’s access and refresh tokens in Company B’s system is allowed under Zoom’s terms if Company A authorizes it and you comply with Zoom’s developer policies and data protection laws. Ensure tokens are encrypted, stored securely (e.g., in a secrets manager), and refreshed automatically using secure server-side logic. OAuth is the only supported method for accessing recordings and transcripts — there’s no alternative method without tokens.
I sincerely apologize for the lack of clarity in my previous explanation regarding the context.
To clarify, I am from Company B.
This application is not intended for general public release or publication to the marketplace. Instead, if Company A wishes to implement it, Company B (myself) will be responsible for hosting the application and managing its setup for Company A’s specific use.
Given this updated understanding, I would be very grateful if you could kindly re-evaluate and answer my previous question.
In this example, an ‘authorization: Bearer {download_token}’ header is used, which does not directly appear to utilize the ‘access_token’ obtained via OAuth.
Could you please confirm my understanding?
While OAuth is required for the process of obtaining the ‘download_url’ and ‘download_token’ themselves, the actual download of the recording or transcript file then uses this separately issued ‘download_token’, rather than directly utilizing the ‘access_token’ acquired through OAuth.
In other words, OAuth is involved in acquiring the ‘download_url’ and ‘download_token’, but the download itself can proceed as long as these two are available. Is this interpretation correct?
If my understanding is mistaken, I would be grateful if you could point it out.
