Zoom Oauth

# 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](https://marketplace.zoom.us/) - Client ID and Client Secret - For S2S OAuth: Account ID

## Four Authorization Use Cases

| Use Case | App Type | Grant Type | Industry Name | |----------|----------|------------|---------------| | **Account Authorization** | Server-to-Server | `account_credentials` | Client Credentials Grant, M2M, Two-legged OAuth | | **User Authorization** | General | `authorization_code` | Authorization Code Grant, Three-legged OAuth | | **Device Authorization** | General | `urn:ietf:params:oauth:grant-type:device_code` | Device Authorization Grant (RFC 8628) | | **Client Authorization** | General | `client_credentials` | Client Credentials Grant (chatbot-scoped) |

### Industry Terminology

| Term | Meaning | |------|---------| | **Two-legged OAuth** | No user involved (client ↔ server) | | **Three-legged OAuth** | User involved (user ↔ client ↔ server) | | **M2M** | Machine-to-Machine (backend services) | | **Public client** | Can't keep secrets (mobile, SPA) → use PKCE | | **Confidential client** | Can keep secrets (backend servers) | | **PKCE** | Proof 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

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

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

### Response

```json { "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