JSON Web Tokens (JWT)

JSON Web Token (JWT) offer a method to generate tokens that provide secure data transmission using a neat and compact JSON object. JWTs contain signed payload that helps establish server to server authentication.

Although JSON Web Tokens can optionally be encrypted using JWE to provide additional secrecy between two parties, we will be focusing on signed tokens. Signed tokens are useful as they provide a way for the receiving party to verify the claims within the token.

Simple change

JWTs have the following essential properties:

Compact: JSON Web Tokens are incredibly compact. This allows them to be sent in something as simple as a URL. Because their size makes them so agile, they can be used in almost any situation.

Self-contained: The JWT contains every piece of information needed about the user. This avoids the need to call the service or database more than is necessary.

JWT Structure

The JWT consists of 3 components:

  • Header
  • Payload
  • Signature

If you put the components together a very generic JWT looks like this:


Let’s take a look at the different components:


The header normally consists of two parts. The alg (Algorithm) and the typ (Type of token), which is JWT.

Header Object:

The Zoom API uses HS256. Use of other algorithms may produce unexpected results.


The second part of the token is the payload, which contains claims. Claims are pieces of information being passed on about the user, along with any metadata that needs to be passed as well. There are three types of claims: registered, public, and private.

Registered Claims: Claims that are predefined by the JWT spec. They are highly recommended because they are meant to be interoperable between services.

Examples of registered claims:

  • iss (issuer)
  • exp(expiration time)
  • sub(subject)
  • aud (audience)

Public Claims: Used as needed by services using JWTs. These should be defined in the IANA JSON Web Token Registry or as a URI that has a namespace that won’t generally collide.

Private Claims: Custom claims created to share information between parties that agree on using them and are neither registered nor public claims.

Below is an example Zoom payload:

Example Payload:

The expiration time (exp) can be defined in a numeric date time format.

The payload is then Base64Url encoded to form the second part of the JSON Web Token.

Though protected against tampering, the information contained in the header and payload is readable by anyone. Do not store confidential information in the payload or header elements of a JWT unless it is encrypted.


To create the signature section of the JWT, use the encoded header and payload with the Secret and HMACSHA256 algorithm to sign the entire package.

For example:

HMACSHA256( base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret)

You can use JWT to establish authentication between Zoom and your app server which will allow your app to consume Zoom APIs.

Supported Libraries

As of today, we support jwt.io libraries. While other libraries can create JSON web tokens, the jwt.io libraries are the most robust. Please make sure to use the libraries on jwt.io.

We also have a great article about using Postman and JWT to get started very quickly with our APIs.

Need help?

The first place to look is on our Developer Forum. If you can't find the answer or your request includes sensitive information, contact Developer Support.