In the section Quickstart - JWT with Zoom there is a paragraph: “Generate your JWT Token using Sever Side Code”
Underneath there are 6 tabs, each illustrating this process using Node, cURL, PHP, Python, Ruby and C#
Only the node example actually generates the JWT and makes a call with it.
All the other language/methods listed do not show the creation of the JWT and automatically assume the user already has the bearer token.
Either the node example should not show the creation of the JWT or (preferably) the other examples should show the JWT acquisition in their respective languages so each example is truly equivalent. It makes no sense to show the full process for node and half the process for the others in the neighboring tabs, it just confuses.
Here is the Python example extended to include the JWT creation:
Hi @Rick1975, thanks a lot for bringing this to our attention. We have now changed the section you mentioned so that it shows how to make API calls using the JWT generated from JWT.io to make it consistent as you suggested. In the future, we will be adding the complete code for generating JWT in multiple languages. For now, we have a working Node.js sample app tutorial in the Quickstart page.
Sharing additionally, I’ve used this in most of my projects:
import jwt
from time import time
import secrets # holds API Key / Secret
def generateToken():
token = jwt.encode(
# Create a payload of the token containing API Key & exp time
{"iss": secrets.API_KEY, "exp": time() + 5000},
# Secret used to generate token signature
secrets.API_SECRET,
# Specify the hashing alg
algorithm='HS256'
# Converts token to utf-8
).decode('utf-8')
return token
We’ll update the samples on the JWT Docs (they’ve been updated significantly since this original post (April 2019))
Yes, but unfortunately, I’ve spent all the time I can on this project for the foreseeable future (since I can’t use it anyway).
However, the biggest issue was a complete misconception of how tokens are generated. It looked like the token was generated by the vendor via a URL that the library contacted, but I see now the token is generated by an algorithm from the library itself (locally) using key + secret provided
Compounding my confusion is the differing use of the ‘iss’ - from the libraries - in the library examples, the iss is a URL, but in the Zoom API, it’s the API key - why the standard allows for this variance blows my mind. I wrote code like a long time ago until I realized that it can cause terrible confusion in the future, which it did here (no fault of Zoom, but I sure wish that standard was rewritten).
@michael.zoom I’m somewhat new to Python. Can you elaborate on using secrets to hold the API Key? All the info I have found says that secrets is for generating secure random numbers.
Hi @tribloom, when putting up sample code, I typically add a secrets.py file I can grab all secret credentials which I can add in a .gitignore file so I never accidentally share any secret credentials publicly.