Authentication and authorization

Discover the authorization server

Production resource: https://api.getridian.com. MCP endpoint: https://api.getridian.com/mcp.

curl https://api.getridian.com/.well-known/oauth-protected-resource/mcp
curl https://api.getridian.com/.well-known/oauth-authorization-server/api/auth

Read the discovered authorization, token, registration and revocation endpoints. Use an OAuth client that supports the advertised flow. Do not hard-code a provider login URL as a replacement for Ridian authorization.

Delegate with Authorization Code and PKCE

Generate state and a PKCE verifier/challenge, use an exactly registered redirect URI and the intended resource, and request the scopes needed for the workflow. The user signs in, selects the workspace and consents. Exchange the returned code using the original verifier. Protect tokens according to the client type; a confidential client’s secret belongs on its backend.

A management credential is not an end-user data grant. Do not use a client_credentials token as a shortcut to arbitrary user calendars. The planned developer-project lifecycle is not established merely because the authorization server advertises that grant type.

Scope families

Calendar reading uses calendar:read; supported writes use calendar:write; RSVP and calendar management have their own scopes. Rooms, tasks, contacts and mail also have separate scopes. The exact per-tool scopes appear in the MCP reference. A scope is still limited by selected calendars, provider rights and workspace policy.

Handle lifecycle changes

Use advertised refresh behavior and treat revoked or rejected credentials as an authorization failure. Do not endlessly retry the same token. Reconnect with user participation when required. Production and test environments must not exchange tokens or customer data.