
Zoom Oauth
Pick the correct Zoom OAuth grant (S2S, user, device, chatbot) before coding tokens and install flows.
Overview
zoom-oauth is an agent skill most often used in Build (also Validate) that selects the correct Zoom OAuth 2.0 flow and grant type for your app scenario.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill zoom-oauthWhat is this skill?
- Quick decision matrix across 4 OAuth 2.0 flows with grant types
- Endpoint split: authorize at zoom.us/oauth/authorize, tokens at zoom.us/oauth/token
- S2S account_credentials for backend automation on your own account
- User authorization_code and device_code paths for multi-tenant and headless devices
- Chatbot client_credentials path scoped to Team Chat bot scenarios
- 4 OAuth 2.0 flows documented in the quick decision matrix
- S2S access token lifetime: 1 hour with no refresh token
Adoption & trust: 839 installs on skills.sh; 19.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are unsure which Zoom OAuth flow fits your SaaS, bot, kiosk, or internal automation, risking failed installs and token handling bugs.
Who is it for?
Indie developers adding Zoom to a backend or marketplace app who need an explicit flow choice before Rivet or raw API code.
Skip if: Integrations unrelated to Zoom identity, or apps whose OAuth model is already approved and documented in repo ADRs.
When should I use this skill?
User is designing or implementing Zoom authentication, marketplace install, or unsure which OAuth grant type applies.
What do I get? / Deliverables
You lock a grant type and credential set, then implement against the documented authorize and token endpoints with correct two- vs three-legged behavior.
- Selected OAuth flow and grant type with rationale
- Credential checklist and token lifetime expectations for implementation
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
OAuth flow choice is decided while integrating Zoom APIs—the canonical Build integrations shelf—even though it informs earlier scoping. Integrations subphase holds third-party auth contracts; wrong grant type breaks marketplace review and runtime token behavior.
Where it fits
Decide if your MVP needs User OAuth because customers connect their Zoom tenants.
Implement token URL calls with the grant type chosen from the decision matrix.
Verify secrets storage and least-privilege scopes match the selected two- or three-legged flow.
How it compares
Zoom-specific OAuth decision guide—not a generic OAuth tutorial and not the Rivet webhook/client layout skill.
Common Questions / FAQ
Who is zoom-oauth for?
Solo builders and small teams shipping Zoom Marketplace or internal automations who must choose among S2S, user, device, and chatbot OAuth paths.
When should I use zoom-oauth?
In Validate when scoping multi-tenant vs own-account access; in Build integrations before token exchange code; whenever grant type ambiguity blocks Zoom app design.
Is zoom-oauth safe to install?
It describes public OAuth endpoints and patterns only—never paste secrets into chat; review Security Audits on this Prism page for the skill package.
Workflow Chain
Then invoke: rivet sdk
SKILL.md
READMESKILL.md - Zoom Oauth
# Zoom OAuth Flows Zoom supports 4 OAuth 2.0 flows. This guide helps you choose the right one and understand how each works. Endpoint split to remember: - Authorization URL: `https://zoom.us/oauth/authorize` - Token URL: `https://zoom.us/oauth/token` ## Quick Decision Matrix | Your Scenario | Flow | Grant Type | |---------------|------|------------| | Backend automation on **your own account** | S2S OAuth | `account_credentials` | | SaaS app for **other Zoom users** | User OAuth | `authorization_code` | | Device without browser (TV, kiosk, IoT) | Device Flow | `urn:ietf:params:oauth:grant-type:device_code` | | **Team Chat bot only** | Chatbot | `client_credentials` | ## Two-Legged vs Three-Legged | Type | User Involved? | Zoom Flows | |------|----------------|------------| | **Two-legged** | No (app acts on its own) | S2S OAuth, Chatbot | | **Three-legged** | Yes (user authorizes app) | User OAuth, Device Flow | --- ## 1. Server-to-Server (S2S) OAuth **When to use:** - Backend automation on your own Zoom account - No end-user interaction needed - Account-wide API access **Grant type:** `account_credentials` **Token lifetime:** - Access token: 1 hour - Refresh token: None (request new token when expired) **Credentials required:** - Account ID - Client ID - Client Secret ### Flow Diagram ``` ┌──────────────┐ ┌──────────────┐ │ Your App │ │ Zoom OAuth │ │ (Backend) │ │ Server │ └──────┬───────┘ └──────┬───────┘ │ │ │ POST /oauth/token │ │ grant_type=account_credentials │ │ account_id={ACCOUNT_ID} │ │ Authorization: Basic {CLIENT_ID:CLIENT_SECRET} │ │──────────────────────────────────────────────────>│ │ │ │ │ Validate │ │ credentials │ │ │ { access_token, expires_in, scope } │ │<──────────────────────────────────────────────────│ │ │ │ API Requests with Bearer token │ │ (valid for 1 hour) │ │ │ ``` ### Implementation ```javascript const axios = require('axios'); const qs = require('query-string'); const getToken = async () => { const response = await axios.post( 'https://zoom.us/oauth/token', qs.stringify({ grant_type: 'account_credentials', account_id: process.env.ZOOM_ACCOUNT_ID }), { headers: { 'Authorization': `Basic ${Buffer.from( `${process.env.ZOOM_CLIENT_ID}:${process.env.ZOOM_CLIENT_SECRET}` ).toString('base64')}`, 'Content-Type': 'application/x-www-form-urlencoded' } } ); return response.data; // { access_token, expires_in, scope, token_type } }; ``` ### Key Points ✅ **Simple:** No redirect URIs, no user interaction ✅ **Secure:** Credentials stored server-side only ✅ **Account-wide:** Single token for all account operations ⚠️ **No refresh token:** Just request a new token when expired (cache with TTL) --- ## 2. User Authorization OAuth **When to use:** - Building a SaaS app for other Zoom users - Users authorize your app to act on their behalf - Need per-user access control **Grant type:** `authorization_code` **Token lifetime:** - Access token: 1 hour - Refresh token: lifetime varies; ~90 days is common for some user-based flows (treat as changeable behavior) **Credentials required:** - Client ID - Client Secret - Redirect URI (must match marketplace app config)