OAuth 2.0 Overview
OAuth 2.0 provides:- Secure delegated access without sharing passwords
- Scope-based permissions to limit what your app can access
- Token-based authentication with automatic expiration
- User consent flow for transparency
OAuth Client Setup
Creating an OAuth Client
- Log in to your Cal.com account
- Navigate to Settings > Security > OAuth Clients
- Click Create New OAuth Client
- Configure your client:
- Name: Your application name
- Redirect URIs: Allowed callback URLs (comma-separated)
- Scopes: Required permissions
Client Types
Cal.com supports two OAuth client types:Confidential Clients
Server-side apps that can securely store secrets
Public Clients
Browser-based or mobile apps using PKCE
OAuth Flows
Authorization Code Flow (Confidential Clients)
Best for server-side applications with a backend.1
Redirect to Authorization
Send users to the Cal.com authorization page
2
User Authorizes
User logs in and grants permissions
3
Receive Authorization Code
Cal.com redirects back with an authorization code
4
Exchange Code for Tokens
Exchange the code for access and refresh tokens
Authorization Code with PKCE (Public Clients)
Best for single-page apps, mobile apps, or applications without a backend.1
Generate Code Verifier
Create a cryptographically random string
2
Generate Code Challenge
Hash the verifier with SHA-256
3
Redirect to Authorization
Include the code challenge in the authorization request
4
Exchange Code with Verifier
Exchange code using the original code verifier
Authorization Endpoint
Step 1: Redirect User to Authorization
Endpoint:GET /v2/auth/oauth2/authorize
Parameters:
Example Authorization URL:
Step 2: User Authorization
The user will see a consent screen showing:- Your application name
- Requested permissions (scopes)
- Option to approve or deny access
Step 3: Receive Authorization Code
After the user approves, Cal.com redirects to yourredirect_uri with:
Token Endpoint
Exchange Authorization Code for Tokens
Endpoint:POST /v2/auth/oauth2/token
Content-Type: application/x-www-form-urlencoded or application/json
For Confidential Clients
For Public Clients (PKCE)
Refreshing Access Tokens
Access tokens expire after 1 hour. Use the refresh token to get a new access token without requiring user interaction. Endpoint:POST /v2/auth/oauth2/token
For Confidential Clients
For Public Clients
Refresh tokens are single-use. Each refresh returns a new access token AND a new refresh token.
Using Access Tokens
Include the access token in theAuthorization header:
OAuth Scopes
Scopes define what your application can access:Booking Scopes
Profile Scopes
Event Type Scopes
Availability Scopes
Webhook Scopes
Team Scopes
PKCE Implementation
PKCE (Proof Key for Code Exchange) adds security for public clients.Generating Code Verifier and Challenge
Client Information
Retrieve OAuth client details: Endpoint:GET /v2/auth/oauth2/clients/:clientId
Request:
Error Responses
OAuth Errors
Example Error Response:
Best Practices
Secure Token Storage
Secure Token Storage
- Store tokens securely (encrypted database or secure storage)
- Never expose tokens in URLs or logs
- Use HTTPOnly cookies for browser-based apps
- Implement token encryption at rest
Token Refresh Strategy
Token Refresh Strategy
- Refresh tokens proactively before expiration
- Implement automatic retry with refresh on 401 errors
- Handle refresh token expiration gracefully
- Queue API requests during token refresh
State Parameter Usage
State Parameter Usage
- Always use the state parameter for CSRF protection
- Generate cryptographically random state values
- Store state server-side or in session
- Verify state matches on callback
Scope Management
Scope Management
- Request only the scopes you need
- Explain scope usage to users clearly
- Handle scope changes gracefully
- Re-authorize if you need additional scopes
Testing OAuth Flow
Use the OAuth playground to test your implementation:- Visit the OAuth Playground
- Enter your client ID
- Select scopes
- Test the authorization flow
- Inspect tokens and responses
Rate Limits
OAuth-authenticated requests have higher rate limits:- OAuth Client: 500 requests per 60 seconds
- Access Token: 500 requests per 60 seconds
Migration from API Keys
If you’re migrating from API keys to OAuth:- Create an OAuth client
- Implement the authorization flow
- Update API requests to use access tokens
- Test thoroughly before switching production traffic
- Maintain API key support during transition
Example Implementation
Next Steps
Rate Limits
Learn about OAuth rate limits
Webhooks
Set up event notifications
API Reference
Browse all available endpoints
Security Best Practices
Implement security measures