Skip to main content
Docket runs an OAuth 2.1 resource server, with the authorization server on the same origin at /api/auth/*.

​
Discovery

Fetch these two and you need nothing else to start. The AS metadata lists the authorize, token, and registration endpoints, S256 for code_challenge_method, and URL-form client IDs.

​
Registering a client

Classic Dynamic Client Registration, RFC 7591:
Returns a client_id.

​
The token exchange

1

Authorize

Send the browser to /oauth/authorize with client_id, scope, and code_challenge. Docket sends anyone unauthenticated to /sign-in first.
2

Exchange the code

PKCE, with resource set to the MCP resource URL per RFC 8707.
3

Call with the token

Authorization: Bearer <token> on every request.

​
Token lifetimes

​
Scopes

Four capability scopes, plus offline_access. The “Grants” column is the exact wording a user sees on the consent screen when your client requests that scope. Ask for the narrowest set that does the job. People decline a read-only integration that asks for work:write and agents:run.

​
Insufficient scope

Docket rejects a write operation from a work:read token with a 403 and:
Authorize again for the wider scope, then retry the call.

​
The limit on every token

A token can never do more than the human who consented to it.
Docket checks the scope first, then that person’s own grants. Someone with view on “Launch v2” cannot write to it with a work:write token. People revoke in Settings → Connected apps, which deletes the consent and its access tokens. Handle it: ask for authorization again.

​
What is not available

No API keys. No long-lived static credentials. The web app’s Better Auth session cookie authenticates first-party requests only.