Connect an app (OAuth)
Connect ChatGPT, Claude or an IDE to Scalix over OAuth 2.1 — no API key to paste, scoped to one project, revocable from the console
There are two ways for an outside app to reach your Scalix account over MCP.
| API key | Connected app (OAuth) | |
|---|---|---|
| Set up by | pasting a secret into the app | clicking Allow on a consent screen |
| Secret handling | you copy it, the app stores it | never shown to you or the app's user |
| Scope | whatever the key was created with | only what you consented to |
| Lifetime | up to 90 days | short-lived, refreshed by the app |
| Revoke | find the right key in API Keys | Settings → Connected apps, by name |
| Counts against | your API key quota | a separate connected-app quota |
Use an API key for your own scripts and CI. Use OAuth when a third-party app is asking on your behalf — it is the safer artifact, which is why it has its own quota rather than consuming key slots.
This page is Scalix acting as an OAuth provider — an app asking for access to your Scalix account. For signing your own users in with Google or GitHub, see OAuth Providers, which is the opposite direction.
Connecting from a client
Any MCP client that implements the 2025-06-18 authorization spec discovers all of this on its own. Point it at the server URL and it will open a browser:
https://api.scalix.world/v1/mcpYou will land on a Scalix consent screen showing the app's name, exactly what it will be able to do in plain language, and which project it is limited to. Nothing is granted until you press Allow.
Read the screen. Any app can register itself with us — that is how the protocol works — so an app you have never heard of can choose any name it likes. When we have not reviewed an app, the consent screen says so, quotes the name it chose, and tells you which host the access is being sent to. If that host is not the app you think you are connecting, cancel.
Scopes
An app receives the intersection of three things: what it asked for, what you hold, and what may be delegated at all. It can never receive more than you have.
Operator-level scopes (*, admin:full, fleet:*) can never be granted
over OAuth, whatever your role. Those stay on API keys, where you paste a secret
you can see and revoke. A consent screen is not a safe place to hand over the
ability to reconfigure IAM.
Access is limited to the single project you pick on the consent screen.
Disconnecting
Settings → Connected apps in the console lists every app with access, what it can do and when it last used it. Disconnecting revokes the grant and its token immediately — the app's next call fails, and it must ask again.
Discovery endpoints
Published for clients that implement the spec; you do not need these by hand.
| Endpoint | What it is |
|---|---|
/.well-known/oauth-protected-resource/v1/mcp | RFC 9728 protected-resource metadata |
/.well-known/oauth-authorization-server | RFC 8414 authorization-server metadata |
/oauth/register | RFC 7591 dynamic client registration |
/oauth/token | authorization code exchange |
An unauthenticated call to the MCP endpoint returns 401 with a
WWW-Authenticate header carrying resource_metadata, which is where a
compliant client starts.
What we support
- Authorization code with PKCE (S256) only. OAuth 2.1 removes the implicit
and password grants, and
plainPKCE, so none of those are accepted. - Public clients. No client secret is issued — a desktop agent cannot keep one, so PKCE is the proof of possession.
- RFC 8707 resource indicators. A token minted here names our MCP endpoint and is rejected anywhere else, so it cannot be replayed against another server.
- Exact redirect-URI matching. No prefixes, no wildcards.
Refresh tokens are not issued yet; a grant is re-authorized when it expires.