Account & User


Contents

1. Account, Users & Big Picture

2. User Type Use Case

1. Account, Users & Big Picture

1.1 Account

Account is all about Zoom services. Based on the type of licenses that you purchased for your account, you will be eligible to enjoy different types of Zoom services.

For instance, an account with Base license type will not be able to access our REST API nor use our SDK, while other license types like API Partner/Pro/Business/Enterprise can. If you registered for a 60-days trial for Zoom Developer, the “Zoom Developer Services” will be temporarily added to your account with Base license. Your account will be able to apply for SDK key & secret, which is needed to pass authentication in our SDK. (To know how to get SDK key & Secret, please visit Get SDK keys & secrets).

If you would like to host multiple meetings at the same time, you will need to purchase multiple Pro/Business/Enterprise licenses, or you can purchase one API Partner license to achieve that.

1.2 Users

User is all about authentication. A user account authenticates a user to enjoy the Zoom services that are provided with your license. The Zoom account that you got from the previous section is automatically associated with a user; this user will be your default user. You can log in as the user to enjoy Zoom services. However, account and user is not always a 1-to-1 relationship — An account can have multiple users.

An account can have 1 or more user(s)
An account can have 1 or more user(s)

In our SDK, we consider different user types under different scenarios:

  • Login User:
    • Uses Zoom username & password do authentication with Zoom
  • Non-Login User:
    • Does not authenticate using Zoom username & password, which includes:
      • User who use SDK feature anonymously
      • User who does authentication using Zoom REST API

In the later section of this page, we will cover the use cases for these two types of users.

1.3 Big Picture

Big Picture
Big Picture

To have a deeper understanding of the relationship between Account, User, and how they affect the implementation of using our SDK, the above “Big Picture” will be helpful.

Account Level & User Level:

All SDK-enabled licenses (API Partner, Pro, Business, Enterprise) supports both Login User and Non-Login User. This means these type of accounts can implement their applications with both types of users under different scenarios.

User Level & Implementation Level:

When implementing for login user, you will need to get the user’s credentials and do authentication with Zoom servers by using built-in SDK functions.

When implementing for a non-login user, you might need to combine REST API and SDK built-in functions. Based on your scenarios, you might need to do authentication with REST API first, and then pass the token in API response to SDK functions to trigger some SDK features.

2. User Type User Case

2.1 Non-login User

Non-login User includes 2 types of user:

  • Type I: User who use SDK feature anonymously
  • Type II: User who does authentication using Zoom REST API

Some SDK features, such as Join Meeting, allow a user to use it anonymously. Type I user can enjoy those features and the authentication & billing process will go to the SDK key & secret owner.

Type II user mainly interacts with our Zoom API by sending requests to our REST API and receiving information back.

To authenticate with our REST API, you can follow these steps:

REST API Authentication Steps

The following steps are simplified and briefly described, if you would like to know more about our REST API Authentication process, please refer to https://marketplace.zoom.us/docs/guides/authorization/jwt

  1. Go to http://developer.zoom.us/ and get API keys & secerets
  2. Use JSON Web Tokens(JWT) library to generate your JWT token that includes your API tokens:
    • In Header, includes: alg: HS256 and typ:JWT;
    • In Payload, includes: iss:<API_KEY> and exp:<expire time>;
    • In Verify Signature, includes your `<API_SECRET>;
  1. Once you have your JWT token, in your following Http Requests’ header, please include your JWT token as a Bearer Token for authentication.

Most of the time, the charges for non-login users will bill to the account owner – the account that owns the SDK key & secret.

In the case of hosting a meeting on behalf of another user(for example, Zoe), the bill will go to the account that is associated with the other user(Zoe) instead of the SDK key & secret owner. To know how to do this and get more information, please visit: Zoom Token & Zoom Access Token(ZAK).

PROS:

  1. Users will not need to log in with their Zoom username and password. No authentication process is needed unless hosting a meeting on behalf of another user.
  2. The app developer can handle the data transmitted between user and Zoom.

CONS:

  1. Some of the built-in SDK functions are not available for Non-login user.

2.2 Login User / SSO User

Login Users will need to enter Zoom login credentials (email/password) and perform authentication with Zoom directly. Single-Signed-On(SSO) User, such as login with Facebook, Google OAuth, third-party SSO, performs the same as log-in user.

PROS:

  1. Users are logged in as themselves. All built-in SDK functions are available to log-in users. Users can host a meeting, start an instant meeting, schedule/list/update/delete meetings, etc. directly.

CONS:

  1. The data transmitted between user and Zoom will not be available to app developer since the user is communicating with Zoom directly.

2.3 Difference & Scenarios

You might wonder: “What kind of user should I choose?”

Feature comparison between licenses:

Account Type Host a scheduled meeting Start an instant meeting Join a meeting Schedule/List/Edit/Delete meeting
Non-login Yes (with ZAK) No Yes No
Login/SSO Yes Yes Yes Yes

The following information might also be helpful based on your use case scenarios:

Different scenarios
Different scenarios

Scenario 1: (Bill on the users)

  • If you would like your app directly communicate with Zoom’s server using your keys & secrets, and user’s credentials.
  • If you want your users to use their Zoom license to enjoy Zoom video services.
  • If you do not want to handle user’s interaction with Zoom, and you want to plug in our SDK and use it.
[For scenario 1, we recommend choosing: Login User]

Scenario 2: (Bill on the meeting host)

  • If you want your user to join a meeting.
  • If you do not care who is using the Zoom video services.
[For scenario 2, we recommend choosing: Non-login User]

Scenario 3: (Bill on your license(s))

  • If you want to use your license(s) for your users.
  • If you want to use your server to do (Zoom services related) authentication.

Note: Regarding scenario 3, you will need to have a table in your database (or any other techniques that are equivalent) that maps each user with valid Zoom credentials.

[For scenario 3, we recommend choosing: Either Login User or Non-login User]

2.4 Examples

Let’s have a look at the following two examples to give your deeper understanding of our user types.

Example 1: Education organization (Large group)

Education organization
Education organization

For large groups like an 4education organization:

James is trying to integrate Zoom SDK into a university app and add “online courses” and “online info section” features. He got the following requirements:

  1. For online courses, students should use their school login credentials to log-in and use this feature. They should not assign a new account and ask them to remember it.
  2. The school admin should be able to see students’ attendance status in the class.
  3. The school admin should be able to see students’ usage status in our system.
  4. For online info section, the school does not care who joins the meeting: the more participants, the better.

Based on the requirements, James selects “Login User” user type for online courses. He creates a table in the database and maps a Zoom user account to each student.

When a student logged in the school’s system and would like to use this new feature, the server gets the student’s Zoom credentials from the database, performs authentication, and helps the student to start the meeting.

For the online info section, James chooses “Non-login user,” students can join an online info session with just one click.

Example 2: Online Fitness Class (Small business)

Online Fitness Class
Online Fitness Class

For small business:

Jane is the founder of a startup company that focuses on delivering fitness information to users. She would like to introduce online fitness classes to her apps.

She analyzes her business and comes up the following requirements:

  1. Since this is a startup company, the budget is very limited. The company cannot afford to purchase licenses for each user.
  2. She would like her users to have full video conferencing services.

Based on the requirements, Jane selects “Login User” account type for her users. She asks her users to use their Zoom credentials to log-in and use video services.