# OAuth sign-in

On Pro and up, people can connect to a hosted MCP server by signing in through your own identity provider instead of using a key. Each server gets its own authorization server at `https://latitude10.tech/oauth/<workspace>/<project>`. It signs nobody in itself: it registers MCP clients, asks the person's consent, sends them to your provider, and issues its own tokens for that one server.

Tested end to end with Auth0.

### 1. Register an app with your provider

Create an OpenID Connect app with the callback URL the MCP page shows, `https://latitude10.tech/oauth/<workspace>/<project>/callback`.

### 2. Connect it

On the project's MCP page, enter the provider's issuer, the app's client id and its secret. The secret is sealed the way the API credential is, and never shown again.

### 3. Choose who may connect

Choose keys only, sign-in only, or both. On "both", agents with a key and people who sign in can use the server side by side.

## Discovery

An MCP client finds everything from the server's `401`, whose `WWW-Authenticate` header points at the protected resource metadata:

| Document | Path |
| --- | --- |
| Protected resource metadata | `/.well-known/oauth-protected-resource/mcp/<workspace>/<project>` |
| Authorization server metadata | `/.well-known/oauth-authorization-server/oauth/<workspace>/<project>` |
| OpenID Connect discovery | `/.well-known/openid-configuration/oauth/<workspace>/<project>`, and `/oauth/<workspace>/<project>/.well-known/openid-configuration` |

The endpoints are `/authorize`, `/token`, `/revoke` and, when dynamic registration is on, `/register`, all under the server's `/oauth/<workspace>/<project>`.

## Clients

- A client can name itself with a client ID metadata document: its `client_id` is an `https` URL.
- Or, if you allow dynamic client registration, it registers and gets a `client_id` starting with `l10c_`.
- Every client is public: no client secret. PKCE with `S256` is required.
- The scopes are `tools` and `offline_access`.
- An owner or admin can revoke any client on the MCP page.

How many clients and sign-ins a server takes depends on the plan: see [Plans and limits](../get-started/plans-and-limits#mcp).

## Tokens

The server issues access tokens starting with `l10a_` and refresh tokens starting with `l10r_`, stored only as hashes. Refresh tokens rotate on every use, and a code or refresh token used twice ends the sign-in.

MCP sign-in tokens are bound to one server and never sent to your API.

Your API gets the stored credential, as with keys, or, if you choose, each person's own token from your provider.

## Claim rules

Rules give people tools by the claims in their ID token: a claim, a value, and the tools it opens, such as `groups` containing `support`. A person gets the server's tools that are on and that a rule they match names. With no rules, everyone who signs in gets every tool that's on. Each refresh asks your provider again, so a person's tools follow their groups.

## Where this comes from

- `app/hosted-mcp/_lib/oauth.ts`
- `app/hosted-mcp/_lib/signin.ts`
- `app/hosted-mcp/_lib/tokens.ts`
- `app/hosted-mcp/_lib/idp.ts`
- `app/hosted-mcp/_lib/server.ts`
- `app/hosted-mcp/_lib/oauth-admin.ts`
- `app/oauth/[ws]/[project]/.well-known/openid-configuration/route.ts`
- `docs/superpowers/specs/2026-10-22-api-platform-enterprise.md`