Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
anthropics avatar

Zoom Oauth

anthropics/knowledge-work-plugins

  • 1.4k installs
  • 23.1k repo stars
  • Updated July 28, 2026
  • anthropics/knowledge-work-plugins

zoom-oauth is an agent skill for reference skill for zoom authentication. use after routing to an auth workflow when choosing app credentials, grant types, scopes, token refresh behavior, or debugging zoom.

About

The zoom-oauth skill is designed for reference skill for Zoom authentication. Use after routing to an auth workflow when choosing app credentials, grant types, scopes, token refresh behavior, or debugging Zoom. Zoom OAuth Background reference for Zoom auth and token lifecycle behavior. Prefer setup-zoom-oauth first, then use this skill for the exact flow, scope, and error details. Invoke when the user asks about zoom oauth or related SKILL.md workflows.

  • 5-Minute Runbook - Preflight checks before deep debugging.
  • OAuth Flows - Which flow to use and how each works.
  • Token Lifecycle - Expiration, refresh, and revocation.
  • Production Examples - Redis caching, MySQL storage, auto-refresh.
  • Troubleshooting - Error codes 4700-4741.

Zoom Oauth by the numbers

  • 1,414 all-time installs (skills.sh)
  • +81 installs in the week ending Jul 28, 2026 (Skillselion tracking)
  • Ranked #223 of 2,742 Automation & Workflows skills by installs in the Skillselion catalog
  • Security screen: MEDIUM risk (skills.sh audit)
  • Data as of Jul 28, 2026 (Skillselion catalog sync)
At a glance

zoom-oauth capabilities & compatibility

Capabilities
5 minute runbook preflight checks before deep · oauth flows which flow to use and how each wor · token lifecycle expiration, refresh, and revoc · production examples redis caching, mysql stora
From the docs

What zoom-oauth says it does

Reference skill for Zoom authentication. Use after routing to an auth workflow when choosing app credentials, grant types, scopes, token refresh behavior, or debugging Zoom OAuth f
SKILL.md
Reference skill for Zoom authentication. Use after routing to an auth workflow when choosing app credentials, grant types, scopes, token refresh behavior, or de
SKILL.md
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill zoom-oauth

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs1.4k
repo stars★ 23.1k
Security audit3 / 3 scanners passed
Last updatedJuly 28, 2026
Repositoryanthropics/knowledge-work-plugins ↗

How do I reference skill for zoom authentication. use after routing to an auth workflow when choosing app credentials, grant types, scopes, token refresh behavior, or debugging zoom?

Reference skill for Zoom authentication. Use after routing to an auth workflow when choosing app credentials, grant types, scopes, token refresh behavior, or debugging Zoom.

Who is it for?

Developers using zoom oauth workflows documented in SKILL.md.

Skip if: Skip when the task falls outside zoom-oauth scope or needs a different stack.

When should I use this skill?

User asks about zoom oauth or related SKILL.md workflows.

What you get

Completed zoom-oauth workflow with documented commands, files, and expected deliverables.

  • OAuth flow selection
  • endpoint configuration
  • grant-type implementation plan

By the numbers

  • Covers 4 distinct Zoom OAuth 2.0 flows with explicit grant types
  • Uses authorization endpoint https://zoom.us/oauth/authorize and token endpoint https://zoom.us/oauth/token

Files

SKILL.mdMarkdownGitHub ↗

Zoom OAuth

Background reference for Zoom auth and token lifecycle behavior. Prefer setup-zoom-oauth first, then use this skill for the exact flow, scope, and error details.

Zoom OAuth

Authentication and authorization for Zoom APIs.

📖 Complete Documentation

For comprehensive guides, production patterns, and troubleshooting, see Integrated Index section below.

Quick navigation:

  • [5-Minute Runbook](RUNBOOK.md) - Preflight checks before deep debugging
  • [OAuth Flows](concepts/oauth-flows.md) - Which flow to use and how each works
  • [Token Lifecycle](concepts/token-lifecycle.md) - Expiration, refresh, and revocation
  • [Production Examples](examples/s2s-oauth-redis.md) - Redis caching, MySQL storage, auto-refresh
  • [Troubleshooting](troubleshooting/common-errors.md) - Error codes 4700-4741

Prerequisites

  • Zoom app created in Marketplace
  • Client ID and Client Secret
  • For S2S OAuth: Account ID

Four Authorization Use Cases

Use CaseApp TypeGrant TypeIndustry Name
Account AuthorizationServer-to-Serveraccount_credentialsClient Credentials Grant, M2M, Two-legged OAuth
User AuthorizationGeneralauthorization_codeAuthorization Code Grant, Three-legged OAuth
Device AuthorizationGeneralurn:ietf:params:oauth:grant-type:device_codeDevice Authorization Grant (RFC 8628)
Client AuthorizationGeneralclient_credentialsClient Credentials Grant (chatbot-scoped)

Industry Terminology

TermMeaning
Two-legged OAuthNo user involved (client ↔ server)
Three-legged OAuthUser involved (user ↔ client ↔ server)
M2MMachine-to-Machine (backend services)
Public clientCan't keep secrets (mobile, SPA) → use PKCE
Confidential clientCan keep secrets (backend servers)
PKCEProof Key for Code Exchange (RFC 7636), pronounced "pixy"

Which Flow Should I Use?

                              ┌─────────────────────┐
                              │  What are you       │
                              │  building?          │
                              └──────────┬──────────┘
                                         │
                    ┌────────────────────┼────────────────────┐
                    │                    │                    │
                    ▼                    ▼                    ▼
          ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐
          │  Backend        │  │  App for other  │  │  Chatbot only   │
          │  automation     │  │  users/accounts │  │  (Team Chat)    │
          │  (your account) │  │                 │  │                 │
          └────────┬────────┘  └────────┬────────┘  └────────┬────────┘
                   │                    │                    │
                   ▼                    │                    ▼
          ┌─────────────────┐           │           ┌─────────────────┐
          │    ACCOUNT      │           │           │     CLIENT      │
          │   (S2S OAuth)   │           │           │   (Chatbot)     │
          └─────────────────┘           │           └─────────────────┘
                                        │
                                        ▼
                              ┌─────────────────────┐
                              │  Does device have   │
                              │  a browser?         │
                              └──────────┬──────────┘
                                         │
                         ┌───────────────┴───────────────┐
                         │ NO                         YES│
                         ▼                               ▼
          ┌─────────────────────────┐         ┌─────────────────┐
          │        DEVICE           │         │      USER       │
          │     (Device Flow)       │         │  (Auth Code)    │
          │                         │         │                 │
          │ Examples:               │         │ + PKCE if       │
          │ • Smart TV              │         │   public client │
          │ • Meeting SDK device    │         │                 │
          └─────────────────────────┘         └─────────────────┘

---

Account Authorization (Server-to-Server OAuth)

For backend automation without user interaction.

Request Access Token

POST https://zoom.us/oauth/token?grant_type=account_credentials&account_id={ACCOUNT_ID}

Headers:
Authorization: Basic {Base64(ClientID:ClientSecret)}

Response

{
  "access_token": "eyJ...",
  "token_type": "bearer",
  "expires_in": 3600,
  "scope": "user:read:user:admin",
  "api_url": "https://api.zoom.us"
}

Refresh

Access tokens expire after 1 hour. No separate refresh flow - just request a new token.

---

User Authorization (Authorization Code Flow)

For apps that act on behalf of users.

Step 1: Redirect User to Authorize

https://zoom.us/oauth/authorize?response_type=code&client_id={CLIENT_ID}&redirect_uri={REDIRECT_URI}

Use https://zoom.us/oauth/authorize for consent, but https://zoom.us/oauth/token for token exchange.

Optional Parameters:

ParameterDescription
stateCSRF protection, maintains state through flow
code_challengeFor PKCE (see below)
code_challenge_methodS256 or plain (default: plain)

Step 2: User Authorizes

  • User signs in and grants permission
  • Redirects to redirect_uri with authorization code:
  https://example.com/?code={AUTHORIZATION_CODE}

Step 3: Exchange Code for Token

POST https://zoom.us/oauth/token?grant_type=authorization_code&code={CODE}&redirect_uri={REDIRECT_URI}

Headers:
Authorization: Basic {Base64(ClientID:ClientSecret)}

With PKCE: Add code_verifier parameter.

Response

{
  "access_token": "eyJ...",
  "token_type": "bearer",
  "refresh_token": "eyJ...",
  "expires_in": 3600,
  "scope": "user:read:user",
  "api_url": "https://api.zoom.us"
}

Refresh Token

POST https://zoom.us/oauth/token?grant_type=refresh_token&refresh_token={REFRESH_TOKEN}

Headers:
Authorization: Basic {Base64(ClientID:ClientSecret)}
  • Access tokens expire after 1 hour
  • Refresh token lifetime can vary; ~90 days is common for some user-based flows. Treat it as configuration/behavior that can change and rely on runtime errors + re-auth fallback.
  • Always use the latest refresh token for the next request
  • If refresh token expires, redirect user to authorization URL to restart flow

User-Level vs Account-Level Apps

TypeWho Can AuthorizeScope Access
User-levelAny individual userScoped to themselves
Account-levelUser with admin permissionsAccount-wide access (admin scopes)

---

Device Authorization (Device Flow)

For devices without browsers (e.g., Meeting SDK apps).

Prerequisites

Enable "Use App on Device" in: Features > Embed > Enable Meeting SDK

Step 1: Request Device Code

POST https://zoom.us/oauth/devicecode?client_id={CLIENT_ID}

Headers:
Authorization: Basic {Base64(ClientID:ClientSecret)}

Response

{
  "device_code": "DEVICE_CODE",
  "user_code": "abcd1234",
  "verification_uri": "https://zoom.us/oauth_device",
  "verification_uri_complete": "https://zoom.us/oauth/device/complete/{CODE}",
  "expires_in": 900,
  "interval": 5
}

Step 2: User Authorization

Direct user to:

  • verification_uri and display user_code for manual entry, OR
  • verification_uri_complete (user code prefilled)

User signs in and allows the app.

Step 3: Poll for Token

Poll at the interval (5 seconds) until user authorizes:

POST https://zoom.us/oauth/token?grant_type=urn:ietf:params:oauth:grant-type:device_code&device_code={DEVICE_CODE}

Headers:
Authorization: Basic {Base64(ClientID:ClientSecret)}

Response

{
  "access_token": "eyJ...",
  "token_type": "bearer",
  "refresh_token": "eyJ...",
  "expires_in": 3599,
  "scope": "user:read:user user:read:token",
  "api_url": "https://api.zoom.us"
}

Polling Responses

ResponseMeaningAction
Token returnedUser authorizedStore tokens, done
error: authorization_pendingUser hasn't authorized yetKeep polling at interval
error: slow_downPolling too fastIncrease interval by 5 seconds
error: expired_tokenDevice code expired (15 min)Restart flow from Step 1
error: access_deniedUser denied authorizationHandle denial, don't retry

Polling Implementation

async function pollForToken(deviceCode, interval) {
  while (true) {
    await sleep(interval * 1000);
    
    try {
      const response = await axios.post(
        `https://zoom.us/oauth/token?grant_type=urn:ietf:params:oauth:grant-type:device_code&device_code=${deviceCode}`,
        null,
        { headers: { 'Authorization': `Basic ${credentials}` } }
      );
      return response.data; // Success - got tokens
    } catch (error) {
      const err = error.response?.data?.error;
      if (err === 'authorization_pending') continue;
      if (err === 'slow_down') { interval += 5; continue; }
      throw error; // expired_token or access_denied
    }
  }
}

Refresh

Same as User Authorization. If refresh token expires, restart device flow from Step 1.

---

Client Authorization (Chatbot)

For chatbot message operations only.

Request Token

POST https://zoom.us/oauth/token?grant_type=client_credentials

Headers:
Authorization: Basic {Base64(ClientID:ClientSecret)}

Response

{
  "access_token": "eyJ...",
  "token_type": "bearer",
  "expires_in": 3600,
  "scope": "imchat:bot",
  "api_url": "https://api.zoom.us"
}

Refresh

Tokens expire after 1 hour. No refresh flow - just request a new token.

---

Using Access Tokens

Call API

GET https://api.zoom.us/v2/users/me

Headers:
Authorization: Bearer {ACCESS_TOKEN}

Me Context

Replace userID with me to target the token's associated user:

EndpointMethods
/v2/users/meGET, PATCH
/v2/users/me/tokenGET
/v2/users/me/meetingsGET, POST

---

Revoke Access Token

Works for all authorization types.

POST https://zoom.us/oauth/revoke?token={ACCESS_TOKEN}

Headers:
Authorization: Basic {Base64(ClientID:ClientSecret)}

Response

{
  "status": "success"
}

---

PKCE (Proof Key for Code Exchange)

For public clients that can't securely store secrets (mobile apps, SPAs, desktop apps).

When to Use PKCE

Client TypeUse PKCE?Why
Mobile appYesCan't securely store client secret
Single Page App (SPA)YesJavaScript is visible to users
Desktop appYesBinary can be decompiled
Meeting SDK (client-side)YesRuns on user's device
Backend serverOptionalCan keep secrets, but PKCE adds security

How PKCE Works

┌──────────┐                              ┌──────────┐                    ┌──────────┐
│  Client  │                              │   Zoom   │                    │   Zoom   │
│   App    │                              │  Auth    │                    │  Token   │
└────┬─────┘                              └────┬─────┘                    └────┬─────┘
     │                                         │                              │
     │ 1. Generate code_verifier (random)      │                              │
     │ 2. Create code_challenge = SHA256(verifier)                            │
     │                                         │                              │
     │ ─────── /authorize + code_challenge ──► │                              │
     │                                         │                              │
     │ ◄────── authorization_code ──────────── │                              │
     │                                         │                              │
     │ ─────────────── /token + code_verifier ─┼────────────────────────────► │
     │                                         │                              │
     │                                         │     Verify: SHA256(verifier) │
     │                                         │            == challenge      │
     │                                         │                              │
     │ ◄───────────────────────────────────────┼─────── access_token ──────── │
     │                                         │                              │

Implementation (Node.js)

const crypto = require('crypto');

function generatePKCE() {
  const verifier = crypto.randomBytes(32).toString('base64url');
  const challenge = crypto.createHash('sha256').update(verifier).digest('base64url');
  return { verifier, challenge };
}

const pkce = generatePKCE();

const authUrl = `https://zoom.us/oauth/authorize?` +
  `response_type=code&` +
  `client_id=${CLIENT_ID}&` +
  `redirect_uri=${REDIRECT_URI}&` +
  `code_challenge=${pkce.challenge}&` +
  `code_challenge_method=S256`;

// Store pkce.verifier in session for callback

Token Exchange with PKCE

POST https://zoom.us/oauth/token?grant_type=authorization_code&code={CODE}&redirect_uri={REDIRECT_URI}&code_verifier={VERIFIER}

Headers:
Authorization: Basic {Base64(ClientID:ClientSecret)}

---

Deauthorization

When a user removes your app, Zoom sends a webhook to your Deauthorization Notification Endpoint URL.

Webhook Event

{
  "event": "app_deauthorized",
  "event_ts": 1740439732278,
  "payload": {
    "account_id": "ACCOUNT_ID",
    "user_id": "USER_ID",
    "signature": "SIGNATURE",
    "deauthorization_time": "2019-06-17T13:52:28.632Z",
    "client_id": "CLIENT_ID"
  }
}

Requirements

  • Delete all associated user data after receiving this event
  • Verify webhook signature (use secret token, verification token deprecated Oct 2023)
  • Only public apps receive deauthorization webhooks (not private/dev apps)

---

Pre-Approval Flow

Some Zoom accounts require Marketplace admin pre-approval before users can authorize apps.

  • Users can request pre-approval from their admin
  • Account-level apps (admin scopes) require appropriate role permissions

---

Active Apps Notifier (AAN)

In-meeting feature showing apps with real-time access to content.

  • Displays icon + tooltip with app info, content type being accessed, approving account
  • Supported: Zoom client 5.6.7+, Meeting SDK 5.9.0+

---

OAuth Scopes

Scope Types

TypeDescriptionFor
Classic scopesLegacy scopes (user, admin, master levels)Existing apps
Granular scopesNew fine-grained scopes with optional supportNew apps

Classic Scopes

For previously-created apps. Three levels:

  • User-level: Access to individual user's data
  • Admin-level: Account-wide access, requires admin role
  • Master-level: For master-sub account setups, requires account owner

Full list: https://developers.zoom.us/docs/integrations/oauth-scopes/

Granular Scopes

For new apps. Format: <service>:<action>:<data_claim>:<access>

ComponentValues
servicemeeting, webinar, user, recording, etc.
actionread, write, update, delete
data_claimData category (e.g., participants, settings)
accessempty (user), admin, master

Example: meeting:read:list_meetings:admin

Full list: https://developers.zoom.us/docs/integrations/oauth-scopes-granular/

Optional Scopes

Granular scopes can be marked as optional - users choose whether to grant them.

Basic authorization (uses build flow defaults):

https://zoom.us/oauth/authorize?response_type=code&client_id={CLIENT_ID}&redirect_uri={REDIRECT_URI}

Advanced authorization (custom scopes per request):

https://zoom.us/oauth/authorize?client_id={CLIENT_ID}&response_type=code&redirect_uri={REDIRECT_URI}&scope={required_scopes}&optional_scope={optional_scopes}

Include previously granted scopes:

https://zoom.us/oauth/authorize?...&include_granted_scopes&scope={additional_scopes}

Migrating Classic to Granular

1. Manage > select app > edit 2. Scope page > Development tab > click Migrate 3. Review auto-assigned granular scopes, remove unnecessary, mark optional 4. Test 5. Production tab > click Migrate

Notes:

  • No review needed if only migrating or reducing scopes
  • Existing user tokens continue with classic scope values until re-authorization
  • New users get granular scopes after migration

---

Common Error Codes

CodeMessageSolution
4700Token cannot be emptyCheck Authorization header has valid token
4702/4704Invalid clientVerify Client ID and Client Secret
4705Grant type not supportedUse: account_credentials, authorization_code, urn:ietf:params:oauth:grant-type:device_code, or client_credentials
4706Client ID or secret missingAdd credentials to header or request params
4709Redirect URI mismatchEnsure redirect_uri matches app configuration exactly (including trailing slash)
4711Refresh token invalidToken scopes don't match client scopes
4717App has been disabledContact Zoom support
4733Code is expiredAuthorization codes expire in 5 minutes - restart flow
4734Invalid authorization codeRegenerate authorization code
4735Owner of token does not existUser was removed from account - re-authorize
4741Token has been revokedUse the most recent token from latest authorization

See references/oauth-errors.md for complete error list.

---

Quick Reference

FlowGrant TypeToken ExpiryRefresh
Account (S2S)account_credentials1 hourRequest new token
Userauthorization_code1 hourUse refresh_token (90 day expiry)
Deviceurn:ietf:params:oauth:grant-type:device_code1 hourUse refresh_token (90 day expiry)
Client (Chatbot)client_credentials1 hourRequest new token

---

Demo Guidance

If you build an OAuth demo app, document its runtime base URL in that demo project's own README or .env.example, not in this shared skill.

Resources

  • OAuth docs: https://developers.zoom.us/docs/integrations/oauth/
  • S2S OAuth docs: https://developers.zoom.us/docs/internal-apps/s2s-oauth/
  • PKCE blog: https://developers.zoom.us/blog/pcke-oauth-with-postman-rest-api/
  • Classic scopes: https://developers.zoom.us/docs/integrations/oauth-scopes/
  • Granular scopes: https://developers.zoom.us/docs/integrations/oauth-scopes-granular/

---

Integrated Index

_This section was migrated from SKILL.md._

Quick Start Path

If you're new to Zoom OAuth, follow this order:

1. Run preflight checks first → RUNBOOK.md

2. Choose your OAuth flow → concepts/oauth-flows.md

  • 4 flows: S2S (backend), User (SaaS), Device (no browser), Chatbot
  • Decision matrix: Which flow fits your use case?

3. Understand token lifecycle → concepts/token-lifecycle.md

  • CRITICAL: How tokens expire, refresh, and revoke
  • Common pitfalls: refresh token rotation

4. Implement your flow → Jump to examples:

  • Backend automation → examples/s2s-oauth-redis.md
  • SaaS app → examples/user-oauth-mysql.md
  • Mobile/SPA → examples/pkce-implementation.md
  • Device (TV/kiosk) → examples/device-flow.md

5. Fix redirect URI issues → troubleshooting/redirect-uri-issues.md

  • Most common OAuth error: Redirect URI mismatch

6. Implement token refresh → examples/token-refresh.md

  • Automatic middleware pattern
  • Handle refresh token rotation

7. Troubleshoot errors → troubleshooting/common-errors.md

  • Error code tables (4700-4741 range)
  • Quick diagnostic workflow

---

Documentation Structure

oauth/
├── SKILL.md                           # Main skill overview
├── SKILL.md                           # This file - navigation guide
│
├── concepts/                          # Core OAuth concepts
│   ├── oauth-flows.md                # 4 flows: S2S, User, Device, Chatbot
│   ├── token-lifecycle.md            # Expiration, refresh, revocation
│   ├── pkce.md                       # PKCE security for public clients
│   ├── scopes-architecture.md        # Classic vs Granular scopes
│   └── state-parameter.md            # CSRF protection with state
│
├── examples/                          # Complete working code
│   ├── s2s-oauth-basic.md            # S2S OAuth minimal example
│   ├── s2s-oauth-redis.md            # S2S OAuth with Redis caching (production)
│   ├── user-oauth-basic.md           # User OAuth minimal example
│   ├── user-oauth-mysql.md           # User OAuth with MySQL + encryption (production)
│   ├── device-flow.md                # Device authorization flow
│   ├── pkce-implementation.md        # PKCE for SPAs/mobile apps
│   └── token-refresh.md              # Auto-refresh middleware pattern
│
├── troubleshooting/                   # Problem solving guides
│   ├── common-errors.md              # Error codes 4700-4741
│   ├── redirect-uri-issues.md        # Most common OAuth error
│   ├── token-issues.md               # Expired, revoked, invalid tokens
│   └── scope-issues.md               # Scope mismatch errors
│
└── references/                        # Reference documentation
    ├── oauth-errors.md                # Complete error code reference
    ├── classic-scopes.md              # Classic scope reference
    └── granular-scopes.md             # Granular scope reference

---

By Use Case

I want to automate Zoom tasks on my own account

1. OAuth Flows - S2S OAuth explained 2. S2S OAuth Redis - Production pattern with Redis caching 3. Token Lifecycle - 1hr token, no refresh

I want to build a SaaS app for other Zoom users

1. OAuth Flows - User OAuth explained 2. User OAuth MySQL - Production pattern with encryption 3. Token Refresh - Automatic refresh middleware 4. Redirect URI Issues - Fix most common error

I want to build a mobile or SPA app

1. PKCE - Why PKCE is required for public clients 2. PKCE Implementation - Complete code example 3. State Parameter - CSRF protection

I want to build an app for devices without browsers (TV, kiosk)

1. OAuth Flows - Device flow explained 2. Device Flow Example - Complete polling implementation 3. Common Errors - Device-specific errors

I'm building a Team Chat bot

1. OAuth Flows - Chatbot flow explained 2. S2S OAuth Basic - Similar pattern, different grant type 3. Scopes Architecture - Chatbot-specific scopes

I'm getting redirect URI errors (4709)

1. Redirect URI Issues - START HERE! 2. Common Errors - Error details 3. User OAuth Basic - See correct pattern

I'm getting token errors (4700-4741)

1. Token Issues - Diagnostic workflow 2. Token Lifecycle - Understand expiration 3. Token Refresh - Implement auto-refresh 4. Common Errors - Error code tables

I'm getting scope errors (4711)

1. Scope Issues - Mismatch causes 2. Scopes Architecture - Classic vs Granular 3. Classic Scopes - Complete scope reference 4. Granular Scopes - Granular scope reference

I need to refresh tokens

1. Token Lifecycle - When to refresh 2. Token Refresh - Middleware pattern 3. Token Issues - Common mistakes

I want to understand the difference between Classic and Granular scopes

1. Scopes Architecture - Complete comparison 2. Classic Scopes - resource:level format 3. Granular Scopes - service:action:data_claim:access format

I need to secure my OAuth implementation

1. PKCE - Public client security 2. State Parameter - CSRF protection 3. User OAuth MySQL - Token encryption at rest

I want to migrate from JWT app to S2S OAuth

1. S2S OAuth Redis - Modern replacement 2. Token Lifecycle - Different token behavior

Note: JWT App Type was deprecated in June 2023. Migrate to S2S OAuth for server-to-server automation.

---

Most Critical Documents

1. OAuth Flows (DECISION DOCUMENT)

[concepts/oauth-flows.md](concepts/oauth-flows.md)

Understand which of the 4 flows to use:

  • S2S OAuth: Backend automation (your account)
  • User OAuth: SaaS apps (users authorize you)
  • Device Flow: Devices without browsers
  • Chatbot: Team Chat bots only

2. Token Lifecycle (MOST COMMON ISSUE)

[concepts/token-lifecycle.md](concepts/token-lifecycle.md)

99% of OAuth issues stem from misunderstanding:

  • Token expiration (1 hour for all flows)
  • Refresh token rotation (must save new refresh token)
  • Revocation behavior (invalidates all tokens)

3. Redirect URI Issues (MOST COMMON ERROR)

[troubleshooting/redirect-uri-issues.md](troubleshooting/redirect-uri-issues.md)

Error 4709 ("Redirect URI mismatch") is the #1 OAuth error. Must match EXACTLY (including trailing slash, http vs https).

---

Key Learnings

Critical Discoveries:

1. Refresh Token Rotation

  • Each refresh returns a NEW refresh token
  • Old refresh token becomes invalid
  • Failure to save new token causes 4735 errors
  • See: Token Refresh

2. S2S OAuth Uses Redis, User OAuth Uses Database

  • S2S: Single token for entire account → Redis (ephemeral)
  • User: Per-user tokens → Database (persistent)
  • See: S2S OAuth Redis vs User OAuth MySQL

3. Redirect URI Must Match EXACTLY

  • Trailing slash matters: /callback ≠ /callback/
  • Protocol matters: http:// ≠ https://
  • Port matters: :3000 ≠ :3001
  • See: Redirect URI Issues

4. PKCE Required for Public Clients

  • Mobile apps CANNOT keep secrets
  • SPAs CANNOT keep secrets
  • PKCE prevents authorization code interception
  • See: PKCE

5. State Parameter Prevents CSRF

  • Generate random state before redirect
  • Store in session
  • Verify on callback
  • See: State Parameter

6. Token Storage Must Be Encrypted

  • NEVER store tokens in plain text
  • Use AES-256 minimum
  • See: User OAuth MySQL

7. JWT App Type is Deprecated (June 2023)

  • No new JWT apps can be created
  • Existing apps still work but will eventually be sunset
  • Migrate to S2S OAuth or User OAuth

8. Scope Levels Determine Authorization Requirements

  • No suffix (user-level): Any user can authorize
  • :admin: Requires admin role
  • :master: Requires account owner (multi-account)
  • See: Scopes Architecture

9. Authorization Codes Expire in 5 Minutes

  • Exchange code for token immediately
  • Don't cache authorization codes
  • See: Token Lifecycle

10. Device Flow Requires Polling

  • Poll at interval returned by /devicecode (usually 5s)
  • Handle authorization_pending, slow_down, expired_token
  • See: Device Flow

---

Quick Reference

"Which OAuth flow should I use?"

→ OAuth Flows

"Redirect URI mismatch error (4709)"

→ Redirect URI Issues

"Token expired or invalid"

→ Token Issues

"Refresh token invalid (4735)"

→ Token Refresh - Must save new refresh token

"Scope mismatch error (4711)"

→ Scope Issues

"How do I secure my OAuth app?"

→ PKCE + State Parameter

"How do I implement auto-refresh?"

→ Token Refresh

"What's the difference between Classic and Granular scopes?"

→ Scopes Architecture

"What error code means what?"

→ Common Errors

---

Document Version

Based on Zoom OAuth API v2 (2024+)

Deprecated: JWT App Type (June 2023)

---

Happy coding!

Remember: Start with OAuth Flows to understand which flow fits your use case!

Environment Variables

  • See references/environment-variables.md for standardized .env keys and where to find each value.

Related skills

vercel-labsAgent BrowserGive their coding agent reliable, high-fidelity control over any website or Electron desktop app.577k39.1kopen.feishu.cnLark ApprovalLet their AI coding agent create, read, update, and approve items in Lark (Feishu) approval workflows without leaving the coding environment.471kopen.feishu.cnLark EventHandle Feishu/Lark bot events, webhooks, and subscription callbacks in agent-driven backend code.471kopen.feishu.cnLark Workflow Meeting SummaryAutomatically generate structured meeting summaries and action items from Lark/Feishu calls without manual note-taking.470kopen.feishu.cnLark Workflow Standup ReportAutomatically generate and post daily standup reports in Lark/Feishu from their workflow and activity data.470kopen.feishu.cnLark Vc AgentGive their coding agent the ability to read, create, and update documents, tasks, and wiki pages inside Feishu (Lark).415k

Forks & variants (1)

Zoom Oauth has 1 known copy in the catalog totaling 16 installs. They canonicalize to this original listing.

How it compares

Use for OAuth grant selection before SDK embedding or REST API calls.

FAQ

What does zoom-oauth do?

Reference skill for Zoom authentication. Use after routing to an auth workflow when choosing app credentials, grant types, scopes, token refresh behavior, or debugging Zoom.

When should I use zoom-oauth?

User asks about zoom oauth or related SKILL.md workflows.

Is zoom-oauth safe to install?

Review the Security Audits panel on this page before installing in production.

Automation & Workflowsworkflow
Browse by category
AI & AgentsFrontend & DesignBackend & DataDev ToolsAutomationTesting & ReviewSecurityMonitoring & CloudDocs & Planning
Design & frontend
Design systemsAnimation & motionAccessibility (a11y)CSS & TailwindUI designUXDesign to codeshadcn/uiLanding pagesBest design skills
Most searched skills
find-skillscavemanfrontend-designbrainstormingsystematic-debuggingstop-slopemil-design-engui-ux-pro-maxkarpathy-guidelinesweb-design-guidelinesreact-best-practicesgrill-meimprovemicrosoft-foundryagent-browser
Browse all listings
All agent skillsAll MCP serversAll marketplacesAll plugins

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.