Latitude 10 docs

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:

DocumentPath
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.

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