OAuth2 Authorization

Vacation Tracker's OAuth2 authorization server. PKCE, Dynamic Client Registration, and metadata discovery for third-party integrations.

Vacation Tracker runs an OAuth2 authorization server at https://auth.vacationtracker.io. Third-party applications, whether server-side (confidential) or user-installed (public), use it to get an access token that acts on behalf of a Vacation Tracker user.

The server supports:

Authorization Code Grant (RFC 6749 §4.1) for confidential and public clients.
PKCE (RFC 7636, S256 only). Required for public clients, optional for confidential ones.
Dynamic Client Registration (RFC 7591) at POST /oauth/register. Public clients only, rate-limited.
Authorization Server Metadata (RFC 8414) at GET /.well-known/oauth-authorization-server, so clients can discover every endpoint and capability.
Refresh tokens valid for 365 days.
Access and ID tokens valid for 60 minutes.

How it works

Your application (or an auto-registered public client) redirects the user to /oauth/authorize with a PKCE code_challenge.
The user authenticates with Vacation Tracker and grants the requested scopes on the consent screen.
Vacation Tracker redirects back to your registered redirect_uri with an authorization code.
Your application exchanges the code (plus the code_verifier) at /oauth/token for access + refresh tokens.
Use the Bearer token against any protected endpoint (/oauth/me, MCP tools, etc.).

Base URL

https://auth.vacationtracker.io

The original host https://api.app.vacationtracker.io/oauth/* still works and will keep working: it points at the same API. New integrations should use auth.vacationtracker.io, which is what the RFC 8414 metadata advertises.

Client types

Client type	Credentials	PKCE	Registration
Confidential (server-side)	`client_id` + `client_secret`	Optional	Manual (contact us) or Dynamic
Public (desktop, mobile, browser)	`client_id` only	Required (`S256`)	Dynamic (self-service via `/oauth/register`)

Public clients don't carry a secret. They authenticate the token exchange with a PKCE verifier instead.

Integrations using this flow

MCP server: AI clients (Claude Desktop, Cursor, Claude Code, and others) connect as public clients, auto-register via DCR, and then run a PKCE authorization code flow.
Custom confidential clients: email developers@vacationtracker.io to register a server-side integration.

Legacy integrations

The Zapier integration predates this flow and still uses the original confidential-client shape (no PKCE, served under api.app.vacationtracker.io). It's documented on the Legacy flow page and stays supported indefinitely. New integrations shouldn't use it.

Next steps

Authorization Code Flow: step-by-step walkthrough with PKCE.
Endpoints: full endpoint reference including DCR and metadata.
Scopes: available permission scopes.
Legacy flow: deprecated confidential-client flow used by Zapier.