DEV Community: Max Mansfield

What I Learned Implementing PKCE for Serverless Zoom Apps

Max Mansfield — Wed, 09 Nov 2022 18:27:32 +0000

If you’re reading this post without a primer on serverless Zoom Apps I recommend checking out the first post in this Serverless Zoom Apps series - Building Serverless Zoom Apps.

This post will take a different, more casual, tone and instead focus on what I was able to learn about my creative process while implementing PKCE. Much of the concepts for this post are inspired by a non-zoomie dev.to post from Remo H. Jansen called Strategic Procrastination and Software Design. Check out that post for even more context.

Security First

When I first set out to write the Serverless Zoom App Sample implementing proper OAuth, with PKCE and a state verifier, seemed to be the most challenging part of development.

Why? Well, there’s nothing more important than the security of your app especially when it comes to authorization. Sure, Zoom is the most secure platform in the world but as a developer one wrong move could throw all that security out the window.

That’s why you’ll see we have a focus on showing security best practices when it comes to the sample applications we publish. It’s critical for your team and ours that Zoom API/SDK credentials are kept secure.

The Road Not Taken

With an eye for security in mind, I quickly found that there was little to no guidance online on how to handle OAuth authorization with PKCE or state verification. Sure, there was some generic information here and there but nothing concrete. Nothing fitting my use case. Nothing you would want to base your best practices app on.

I could set up firebase user authentication but that seemed like overkill and a lot of complexity for what was supposed to be a quick start. I needed a method to identify a user behind the scenes to store a unique state and verifier on the backend.

No, I didn’t need to find a method. I needed to find the best method.

What is PKCE anyways?

Let’s take a step back. Why exactly do I need to implement PKCE? What are the benefits it provides?

PKCE (pronounced as pixie) is an extension to the Authorization Code OAuth flow that was originally designed for mobile applications that were unable to keep a client secret secure.

These days, we use it with web development along with our client secrets to prevent CSRF attacks as well as an injection of an authorization code from a bad actor.

If you want to get into the nitty gritty, I recommend reading the RFC Specification but I’ve pulled some of the important parts out so we can see what exactly PKCE is:

This extension utilizes a dynamically created cryptographically random key called "code verifier".

A unique code verifier is created for every authorization request, and its transformed value, called "code challenge", is sent to the authorization server to obtain the authorization code.

The authorization code obtained is then sent to the token endpoint with the "code verifier", and the server compares it with the previously received request code so that it can perform the proof of possession of the "code verifier" by the client.

This works as the mitigation since the attacker would not know this one-time key, since it is sent over TLS and cannot be intercepted.

In other words, for each request to authorize we need to create a session for that user so that we can associate their request with a uniquely generated “Code Verifier”.

What About the State Parameter?

The state parameter has a similar use as a code verifier and code challenge except we can customize that parameter to hold whatever data is useful for us.

In this fashion, not only does it serve as a CSRF protection mechanism but also allows us to pass data to our Zoom App.

If you’re interested in learning more about using a state parameter I recommend checking out this guide from Auth0.

A Point of Saturation

After even further research I had a few options none of which seemed to fit exactly what I needed. I almost convinced myself to write a signup and login flow at one point. The irony here is that the development for that login code would likely eclipse that of the to-do app it was supposed to federate.

Frozen from too many choices or perhaps just an inability to find the right solution I decided to postpone the crux of the project - the PKCE implementation. Instead, I would write a basic Cloud Function OAuth implementation and would extend it when I continued my research.

When I made this decision it felt like a major bump in the road. I was looking behind me trying to decide if it was too late to turn around and go back or if I could manage to make it to my destination.

Nevertheless, I continued down my path of writing a serverless Zoom App saving the PKCE implementation for when I had everything else sorted out.

Security Last

Fast forward a couple of weeks and Zoomtopia is right around the corner. My to-do app is complete and I can rest easy. Not only that but it has passed most approvals and is just awaiting security approval before being published.

I’m getting ready for bed and planning what I’m going to do for the next day when I remember my recently submitted security review. I begin wondering when I’ll hear back from our team and what sort of feedback I’ll hear from them.

Concerned that I might not pass my review in time I recollect my past sample applications thinking of the various feedback I’ve had to address in the past and how long that took me.

I console myself by confirming I have my bases covered and the changes should be quick to address. After all, it’s not like I’ll have to implement any new functionality.

That’s when it hit me. PKCE! I completely forgot about PKCE and I had done none of the research I planned.

Bedtime was over it was now time to panic!

Get Back to Work

I ran downstairs to my office and immediately started my laptop. Hoping that my security review hadn’t been seen so I could at least spare myself the embarrassment of submitting an insecure app for review.

For the first time ever, I’m happy to see that no one has gotten back to me on my review. I open up my IDE to work on my to-do app with only panic at the forefront of my mind.

I looked at my code for a moment, focused my mind on the problem and to my great surprise, I knew exactly what to do.

It was so obvious! How was I confused before? Well, I’m certainly confused now as I begin writing this PKCE implementation at lightning speed. My first test works. Wait. What?!

How is this happening? This is working too well. I test some more before realizing it’s only been about 30 minutes but everything seems to be working. I must be sleep deprived, I think.

I push my changes up to my repository and await the harsh reality that will be the upcoming security review.

Lessons Learned

If it isn’t clear, my app did indeed pass the security review and you can download it right now on our GitHub!

So the question is, without putting additional research into PKCE, how was I able to implement it? Well to be honest that would be nearly impossible.

The key here is that I strategically procrastinated the implementation while accidentally researching everything about Firebase and PKCE along the way. What I mean by this is that even though I wasn’t directly focused on OAuth or PKCE I would mull it over and ponder it as I went through the development lifecycle.

For instance, when I stumbled across the Firebase Authentication documentation I found myself reading at length about anonymous authentication and the process for anonymous users. Almost without thinking about it, I filed that away for later.

On another occasion, I’m looking through previous apps to pull sample code and I find myself reviewing my old PKCE implementation. Taking a moment to remember just why PKCE is useful and what it is used for as we covered above.

Without realizing it, I had spent the last two weeks taking every opportunity possible to learn about how to implement PKCE with a serverless architecture.

Strategic Procrastination

It wasn’t until after my security review was approved that I found a name for what I did. After reading the blog Strategic Procrastination and Software Design it became clear that this was part of my creative process when my mind is overwhelmed with a topic.

As explained by Remo H. Jansen,

Strategic procrastination involves taking massive action in both physical and mental aspects. You put in extreme labor, back off from it to recover, allowing your subconscious mind to process all of it and then enter the fray with newfound vigor.

Remo goes on to explain the 5 stages of strategic procrastination:

1. Have a vision or goal.
Start working on them immediately, today, as soon as possible.

2. Take massive action every single day
Move closer constantly. Put in significant amounts of effort and work. You have to become obsessed with your thing if you want extraordinary results.

3. Reach a point of saturation
Exert your mental powers and feel as if your mind has been drained like a sponge.

4. Initiate strategic procrastination
Back off and focus on recovery. Walk, exercise, play around and relax. Don’t forget about your work entirely but don’t manically focus on it either. Ponder over it quickly but not too hard.

5. Get back to work
After proper recollection of resources, you have to start putting in the work again; otherwise, you’re only procrastinating not strategically procrastinating. This part is essential and the one in which you produce your most excellent work. You re-enter the zone with newfound vigor and creative insight so that you could achieve glory.

The Implementation

Strategic or not, what did this procrastination lead to? What was the ultimate solution to implementing PKCE with a serverless application?

Firebase Firestore

Reminding myself of why and how PKCE is used throughout the development of the project helped to clarify the requisites for a secure PKCE implementation. In the simplest terms, I just needed to be able to store a random value for a specific user and then recall that value when they came back to my site.

I knew that I was already using Firebase Firestore for storage so that problem was solved but I wasn’t sure how I could map user sessions together.

Anonymous Authentication

We can solve the need to map requests to users by using Firebase Anonymous Authentication. This creates temporary accounts that are tied to a user's session. Using this authentication, we now have a User ID that we can use in our Firebase Cloud Functions.

Let’s take a look at the code. Here we have the function responsible for installing the app.

On line 72 you can see that we immediately have access to the context.auth.uid variable. This is thanks to enabling anonymous authentication. We use the uid along with a random value in our state to ensure that the state is unique for each request while also passing the uid to the redirect URL.

One line 73 we are generating a random Code Verifier for use with PKCE. Looking down at line 98, we can see that we then store this in our Firestore database. We set the ID of the document as the uid so that we can reference it later and then simply store the state and verifier values that we generated.

Now, let’s take a look at the function that serves as our redirect URL for OAuth. This function is responsible for receiving the state and verifier information that we set previously.

On line 119 we are parsing out the uid from the state value. Then on line 127 we’re fetching the state and verifier parameters that we stored earlier using that uid value.

Then on lines 135 - 139, we are validating our parameters. Finally, we use the Zoom OAuth API along with our verifier to get our accessToken and use the Zoom API to deep link our user to our app.

What’s Next?

Make sure to follow us on dev.to so you can stay updated on our latest blogs. If you haven’t already check out our github! Get started right away using our sample application so you can build out the next killer Zoom App!

Also, make sure that you check out Strategic Procrastination and Software Design if your brain works like mine does.

Thank You for Reading!

Thanks for taking the time to read this post. If you have any lingering questions or just want to chat about building the future of collaboration please head over to our Developer Forum.

Happy Coding!

Building Serverless Zoom Apps

Max Mansfield — Wed, 09 Nov 2022 18:17:28 +0000

When we build Zoom Apps, we’re creating tools that have the potential to be used by millions of people every day to do their jobs. The difficulty here is that we’re writing real-time, collaborative, and distributed apps using monolithic tools that are designed to solve different problems.

We can deploy a docker image and orchestrate clusters to make sure we have a highly available and scalable application but at the end of the day, we are still responsible for maintaining and updating that server infrastructure to make sure our app continues to work for all users.

Whether we’re staying late yet again dealing with crashed servers, or deciphering system configuration in an attempt to secure and optimize our app there is a lot to think about for a backend development team.

Often, we end up working against our tools rather than with them which is ironic when we’re configuring these servers and orchestrating clusters just to reliably run the logic that makes our app awesome.

Today, let’s talk about improving our developer experience in a production-ready environment way that allows us to experiment, fail fast and win big

What to Expect from this guide

I’m hoping you can answer the following questions after this guide:

What is a “Serverless” App?
How can we make a Zoom App serverless?
What is the quickest way to get started?

What is a Zoom App?

For readers that are unfamiliar with what exactly a Zoom App is I recommend checking our Introduction to Zoom Apps series.

In one sentence, I would say it’s a super-powered web app. Meaning, you’ve got the flexibility of a web app with the reach and in-client features of Zoom right at your fingertips.

With the Zoom Apps SDK, we can use JavaScript or TypeScript to create first-class applications to enhance the meeting experience.

What’s the catch?

So we know that Zoom Apps are super-powered web apps which means they have the same considerations as a typical web app.

This is great for web developers because it means we are working in a familiar landscape but it’s key to understand that we have the same challenges as writing a typical web application.

What will our server infrastructure be?
How can we ensure high availability?
Cluster Orchestration? Load Balancing?
What about our databases?

The list goes on! There’s certainly a lot we need to think about as developers to get started building.

Why is that a Catch?

it might be easy to think those are the components of a web app. That’s simply the boilerplate which is why I think a lot of developers find the initial setup and configuration of a production-ready project to be one of the biggest barriers to experimenting and failing fast.

For a lot of developers, I think the problems we like solving are quite a bit more nuanced and we don’t want to maintain what is effectively boilerplate for our app.

When we look at the server infrastructure including our storage, authentication, user models, and content delivery as part of the boilerplate we can start to see how monolithic tools and technologies break down for us.

Instead, if we can reuse some of the boilerplate server code that we need and modularize our infrastructure we can provision, develop and deploy applications instantly.

That’s where serverless apps come in!

What Makes a Serverless App?

Serverless technology is based on a microservice architecture that exposes one or more services to be used as modular units for your application per your use case.

What does this look like in the real world? It means that you don’t have to think about any of the servers for your apps. Sure there is a computer somewhere that is running your code but the best part about serverless architecture is that you don’t have to factor in the underlying technologies when building out your next killer app.

Instead, we’ll be using a platform that encompasses the backend and logic of a server that we can easily consume in our front-end application.

Backend as a Service (BaaS)

Not thinking about servers means using a backend as a service where you don’t have to worry about updating your operating system or patching your database.

Where cloud storage is automatically configured and your frontend code is hosted through a CDN. All of this represents hours and hours of research, setup, testing, and implementation on its own.

I really can’t overstate how significant of a head start this is on developing an MVP that you would want as your product.

Functions as a Service (FaaS)

While we have the backend systems available as services, we still need a way to implement our custom server logic.

Luckily serverless architectures provide functions as a service which are short-lived instances that run your backend logic.

As these instances are so temporary, you’re only charged for exactly what you use and you never have to deal with runtime errors related to out-of-date system dependencies

Pros and Cons

As we know, nothing is perfect so let’s take a moment to go over some of the Pros and Cons of serverless applications:

Pros

Cost Effective
Easily Scalable
Zero Maintenance
Shorter Time-to-Market

Cons

Complex Debugging
Vendor Dependency
Multi-Tenancy
Costly Compute Tasks

Looking at the pros, we’ve covered most of this already as we’ve learned about serverless architecture. We have less to manage, and containerized code with more precise billing. This means less of a headache for us and therefore a shorter, and cheaper, time to market.

It’s when we look at the cons of serverless applications that we can learn more.

Complex Debugging

Since your code is running on another server, debugging can sometimes be time-consuming and complex with server errors on a cloud-based server. With the sample code that we’ll be using in this guide, the use of Local Emulators greatly improves our debugging experience.

Vendor Dependency

As there currently isn’t an ORM of sorts for cloud vendors often writing a serverless application can lock you into a specific vendor. Of course, you can make the migration between services relatively pain-free by wrapping your database calls with your multi-vendor API.

Multi-Tenancy

This is a new concern for our security engineers out there that are looking to adopt serverless applications. Due to the shared nature of most cloud computing servers, there is a risk that vulnerabilities such as privilege escalation or memory leaks can lead to data breaches.

Costly Compute Tasks

Running costly compute tasks on a FaaS is inadvisable and instead should only be used for short-lived tasks like a typical server route. Using the ephemeral containers which are charged based on usage time to compute data can not only cost quite a bit but also take too long.

Instead, the cloud platform likely provides other compute or VPS services that would be more applicable.

Using Firebase

Firebase is a Platform as a Service (PaaS) that provides Cloud Functions and Backend services. It has usable free tiers and intuitive paths to get started quickly.

These techniques and tips apply to any Paas/IaaS provider through the steps to implement will vary.

Throughout this guide, we will use three functions of firebase

Cloud Functions

These fulfill the FaaS requirement for our serverless application quite well. As described by Firebase these will allow us to:

Automatically run backend code in response to events triggered by Firebase features and HTTPS requests

Firestore

This will allow us to sync data between our various clients without having to put any thought into database configuration. Just make a schema for the shape of our database and push data!

Flexible, scalable NoSQL cloud database to store and sync data for client and server-side development

Hosting

This is how we will serve content to our users. We can set it up as a dynamic or static host and either way it will automatically be configured to scale and distribute our content globally.

With a single command, you can quickly deploy web apps and serve both static and dynamic content to a global CDN

Replacing our Server

As some of you may know, we have a Basic Sample Zoom App that uses a simple express server to demonstrate the bare minimum needed to get started with a Zoom App.

Being a basic server, it’s still responsible for quite a bit! Let’s take a look.

Zoom Apps Authorization Flow

Our server is currently responsible for acting as the redirect URL for our Zoom App which can receive the access token. This is something we specifically need a server for because we can’t expose the token to a web client.

This is where Cloud Functions come in. Cloud Functions allow us to:

Receive the Authorization Code
Obtain the Access Token
Make Requests to the Zoom API

and so much more!

OWASP Headers

If you’re already a Zoom App Developer you know that the OWASP security headers are essential for getting your app up and running. Without them, you’ll see what I call the white screen of death - a blank zoom app with only a console error to guide you.

When we’re working with the sample code today, we can set production headers in firebase.json and use the development server configuration to set the development headers.

Luckily, if you clone the code you’ll see that this is already done for you.

Zoom Apps Context Header

If you have looked at any of our Zoom Apps sample applications so far, you’ll notice that they decrypt and unpack the Zoom Apps Header that is sent by the Zoom client.

When we don’t have direct access to a server, and in this case, we are using a Single Page Application, then how can we read the request headers?

The answer is that we don’t. We can get all the information we need from the Zoom Apps JS SDK. While we could set a cloud function as our homepage to decipher the headers this is impractical when we have the Zoom Apps SDK.

Client Side Routing

For readers that haven’t used client-side routing before, it is incredible! Instead of making requests to the server, we can use JavaScript bundles and instantly load the new chunk of code.

This means fewer requests to your server, less bandwidth, and instant load times.

A Look at the Demo App

Our sample today can be found on our GitHub and is a serverless, single-page, todo application. Yes, it uses all the buzzwords and is built on a modern tech stack around an intuitive developer experience.

Clone The Repo Here

Configuring Firebase

This step should be very simple which is one of the reasons I built this sample around Firebase.

Join a Free Account
Create a New Project
Enable Hosting, Functions & Firestore
Set Up Secrets Manager

Firebase Development

When working with Firebase, you’ll want to make use of the Local Emulators.

What are Local Emulators? They are local services that emulate the serverless architecture on your local system. This allows you to test and debug locally which offers instant access to more detailed debug logs

Likewise, you’re able to make changes to your application locally and retain hot reloading which drastically improves productivity

Once we have the emulators running, we can proxy the function emulators using our development server so that our OAuth Redirect URL can be used. This is all set up in the sample application that we have.

Configure your Zoom App

When working with a development environment, we have a .secrets.local file for our Zoom App credentials. However, when we are running in a production environment, we are lucky enough to have a Secrets Manager to create, rotate and manage application secrets.

In both cases, the secrets will be automatically injected into our application environment.

In the image below, you can see that for development we are using a tunnel to our local system for our development credentials (Ngrok in this case). Notice the format of the redirect URL matches the path to a local emulator.

For production environments, we are using the actual hosting URL and cloud function URL provided by Firebase. This enables a smooth developer experience with a logical separation of environments.

What’s Next?

If you haven’t already check out our github! Get started right away using our sample application so you can build out the next killer Zoom App!

If you’re feeling comfortable with Cloud Functions and Zoom Apps take a look at the next post in this series - What I Learned Implementing PKCE for Serverless Zoom Apps.

Thank You for Reading!

Thanks for taking the time to read this guide. If you have any lingering questions or just want to chat about building the future of collaboration please head over to our Developer Forum.

Happy Coding!

How to Setup the Basic Zoom App Sample

Max Mansfield — Tue, 21 Jun 2022 16:01:46 +0000

Welcome to part 3 of our Getting Started with Zoom Apps series! Part one of our series covered an overview of Zoom Apps, and in part two, we even created one. This section will look at setting up and running our sample Hello World Zoom App.

If you're following along, you should have the Client ID and Client Secret from your Zoom App and an OAuth Redirect URL from a running Ngrok tunnel.

Prerequisites

Node.JS (NPM)
A Zoom App on the Zoom Marketplace
Client ID and Client Secret
Redirect URL

About the App

The sample Zoom App code we will be running today uses vanilla JavaScript and Express to demonstrate the bare minimum code needed to get up and running while still following best practices.

On that note, this app doesn't really do much. It's a template for other sample applications and is designed to be extensible.

Setup and Install

Now we're going to set up the code needed to run the app and all the dependencies. First, clone the git repository found here:

https://github.com/zoom/zoomapps-sample-js

Use NPM to install dependencies:

$ npm install

Add Credentials

Installing dependencies creates the .env file that holds our application secrets while developing in a secure environment.

Open the .env file and follow the instructions to fill out the fields. The SESSION_SECRET field will already have a random value generated for development.

# Client ID for your Zoom App
ZM_CLIENT_ID=

# Client Secret for your Zoom app
ZM_CLIENT_SECRET=

# Redirect URI set for your app in the Zoom Marketplace
ZM_REDIRECT_URL=

# Sign Session Cookies
SESSION_SECRET=3e571b471f611f7cae69cadcaa786e82a93609ffdcfe9bab93bf52f356a4d9ae

Start the App

Run the app in development mode to use the credentials from the .env file and watch for changes to files:

$ npm run dev

This starts our app on port 3000 by default, but you can set the PORT environment variable to change that.

Using the App

Navigate to your Ngrok URL in your browser to display your Zoom App home page:

Our Zoom App knows that we're running it from the browser and gives us the option to install the app.

Click the install link and follow the prompts to authorize the app. If you authorized your app when creating it, then this will open your app in the Zoom Client:

Now, you can see our Zoom App is running directly from Zoom!

Great job! You've created, installed, and run your Zoom App. Feel free to take a look at the code, and please see our next section for information on how you can continue your journey as a Zoom App Developer.

Continue Learning

Thank you for reading through this three-part series introducing Zoom Apps! I hope this series has been helpful and you're inspired to create something awesome with all the tools that Zoom Apps provides.

I've included links to our documentation and further resources on learning about Zoom. Happy Coding!

Documentation

Video Guides

Sample Apps

Setting Up Your Zoom App

Max Mansfield — Tue, 21 Jun 2022 16:01:26 +0000

Thanks for joining us again for part two of our three-part series on Zoom Apps. If you missed it, the last section introduced what Zoom Apps are and what they can do. In this section, we'll go over how we can create a Zoom App and how we can best use our granular permissions system.

Before we get started, you'll need a Zoom user account with permission to create a Zoom App. If you're the account admin, you're all set. If you're unsure what your role is, you can check the support article here.

Prerequisites

Ngrok
A Zoom account
A Zoom user that has Zoom App Developer permissions in their role

Using Ngrok

If you want to follow along with configuring your app and setting up our sample Zoom App, you'll need Ngrok or another local tunneling tool.

Start a Ngrok tunnel and leave it open while testing the sample app:

$ ngrok http 3000

Save the HTTPS forwarding URL that you see for later and leave Ngrok running. We'll refer to this URL as https://example.ngrok.io.

Note, unless you're using a paid Ngrok plan, Ngrok will regenerate a new URL each time you restart, so we'll only want to use this for quick testing purposes.

Ngrok can also impact the latency and bandwidth of the network connection, so you shouldn't use it for performance or latency testing.

Create a New Zoom App

Now that you're settled and logged in to your Zoom account, head over to the Zoom App Marketplace at https://marketplace.zoom.us to start.

Click the dropdown that says Develop and then click Build App:

You should see a few App types listed on the next page. Click Create under the tile that says Zoom Apps. In the dialog that appears, fill out the initial information:

App Name

As you may have guessed, this is your app's name. Choose wisely, as you can't change the app's name from now on, and this will be the app's name if published to the Zoom App Marketplace.

Choose app type

At the time of writing, only user-managed apps are available to create. With user-managed apps, each user will install and authorize the app individually. The access token has data access scoped only to the authorized user.

Distribution

Leave this option checked if you plan to list your app on the Zoom App Marketplace so that anyone with a Zoom account can install it.

After you click Create, a new Zoom App is created and will be ready to configure.

Configure Your App

Now that you've created your app, you should see a page similar to this:

Let's review some essential tabs we can use to configure our app.

App Credentials

Home URL

This is the landing page for your Zoom App and the URL that Zoom will display when a user opens your app. To run the Sample App, enter your Ngrok URL here.

Client ID and Client Secret

The Client ID and Secret are similar to a username and password of an app. In that sense, you'll always want to securely store your credentials and never share them or commit them to your repositories.

Redirect URL for OAuth

The OAuth Redirect URL is the URL to which the OAuth flow will redirect once the user has authorized your app. Make sure you add this URL to the OAuth allow list and the Domain Allow List below.

To set this up with our sample app, enter your Ngrok URL with the /auth route appended:

https://example.ngrok.io/auth

OAuth Allow List

These are the domains the app can use for OAuth redirects, so make sure to add the Redirect URL from above here.

Domain Allow List

First, we'll want to add the domain for our OAuth Redirect URL and Home page here. This is the domain from our Ngrok URL.

The Sample Apps also use our CDN for the SDK to make sure you add the domain for that CDN:

appssdk.zoom.us

Additionally, if we connect to any domains from our app, we'll want to add them here too.

Information

Make sure to fill out the information tab with details relevant to your app.

Features

Now that we have our credentials and our app connects to our domain (our Ngrok URL), we are ready for the fun part.

When we navigate to the Features Tab, we can see a lot of different functions and capabilities we can enable for our Zoom App to use.

Access to a feature or function will need to be enabled here for your app to use. Here is where you'll enable APIs or features like Guest Mode or Collaborate Mode. Note: If you add new features to an existing app, they can be used by reinstalling your app.

To set up our Hello World app, we need to click Add APIs under the Zoom App SDK section and select the shareApp API.

Scopes

Moving on to the scopes tab, we can see that we can add OAuth scopes which define the data our credentials can access. Since we're just setting up a simple app today, select the zoomapp:inmeeting scope and click continue.

Install Your App

Navigate to the Activation tab and click the Add button to install your app:

🎉 Congratulations! 🎉 You've just created your very own Zoom App.

Run Your App

Now that we have our credentials and installed our app, we're ready to set up our Hello World Zoom App and run it from the Zoom Client.

Join us in part three of this series, where we'll use our credentials and Ngrok URL to open our app.

Introducing Zoom Apps

Max Mansfield — Tue, 21 Jun 2022 16:01:12 +0000

Zoom Apps allow you to bring your web applications front and center within Zoom Meetings and Webinars. They integrate seamlessly with Zoom using a lightweight and framework agnostic JavaScript SDK that enables you to provide a unique experience to participants and hosts of your meetings.

With a broad feature-set to customize the meeting experience, it's simple to build the next must-have meeting app using familiar tools and web technologies or bring over your existing killer app.

What's more? Getting started with Zoom Apps couldn't be quicker! Just create an app on our App Marketplace and spin up one of our sample applications to have the power of Zoom at your fingertips.

Throughout this three-part series, we'll take an in-depth look at what Zoom Apps are, how to configure an app on our App Marketplace and how you can get started running a Hello World Zoom App right now.

How does it work?

Zoom Apps are web apps with added APIs and features from the Zoom desktop and mobile clients. Building Zoom Apps gives you the wide-ranging functionality of a web app and the ability to tailor the experience to match your app's best in-meeting and post-meeting UX. Zoom Apps can be installed directly from the Zoom client or Zoom App Marketplace and will open your web app as a view embedded within the Zoom Client.

Using granularly scoped OAuth mechanisms and a lightweight JavaScript SDK, we can bring opportunities for new use cases and enhanced meeting experiences.

What can Zoom Apps do?

Your web app will display by default as a panel on the side of a meeting, but you can also change this view in various ways based on your app's context. We can expand or pop out this view, fill the entire meeting space, and dynamically customize the experience for each user using features like Collaborate Mode or our Layers API.

Meeting Bots

Let your app interact with users and join the meeting as a helping hand with our new Meeting Bot feature powered by Zoom Apps and the Zoom Meeting SDK.

Collaborate Mode

Collaborate Mode shares a collaborative app and offers a frictionless method for everyone to join in on our favorite collaborative team tools.

Immersive Mode

Our Layers API enables a new immersive opportunity for apps using Zoom's powerful layering system.

Manage Breakout Rooms

Split the meeting into smaller sessions to enable a customized collaboration and networking flow using our Breakout Rooms API.

Ready? Set. Zoom!

Now that we know what Zoom Apps are let's create our credentials for the app and test out one of the sample applications available to us.

In the next part of this series, we'll look at creating and configuring your application on the Zoom Marketplace.