SDK client id and secret management

To initialize Android SDK, we need to call initialize using sdk client id and secret. That means we have to put client secret somewhere in the app package. Which essentially means it is publicly available (you can hide or obfuscate it, but cannot secure it).

My questions are, should we be worried about stealed client secret? What is the consequence of the client secret stealed and abused by others?

Or, is there any other way to initialize SDK without embedding client secret into app bundle?


Hi jiulongw,

Thanks for using Zoom SDK and thanks for the questions. We highly discourage the way of hardcoding Zoom credentials (SDK keys, secrets, etc.) in your code. We have the credential fields hardcoded in our demo app but it is for demo purpose. Please see our disclaimer:

There are multiple ways of securing your keys. Please note that you only need to initialize the Zoom SDK if and only if you would like to use any Zoom services. The following are 2 examples of how to deal with Zoom credentials:

  1. Store the credentials in a local file(e.g: yaml file), and encrypt it. Get the decrypt key from somewhere else to decrypt the file, and get the keys&secrets.
  2. Get the keys and secrets from your backend.

You can use any ways(not only the above 2) that you prefer to deal with your Zoom credentials. It is really based on your system design and use case scenarios.

Hope this helps. Happy Zooming!

Hi Carson,

Thanks for the quick response. Yes I can encrypt it in a local file or get it from backend, but still it does not protect the secret. For example, attacker can inject code to print out the secret right before the call to zoom sdk initialization.

A preferred way is to store secret in backend and use it to sign some sort of a token for zoom sdk to use. The token can be one-time usage or it can be used multiple times. The point is even if the token is compromised, secret is still safe and token can be easily revoked.



Thanks for the reply and thanks for sharing the idea. Yes, I understand, the way you are mentioning is something like OAuth and it is indeed more secure. Unfortunately, we do not have such a mechanism from our side now thus you might need to implement this OAuth process on your side.

Hope this helps. Thanks!