Skip to main content
FrontMCP supports Remote OAuth (connect to an external IdP) and a built‑in Local OAuth provider. You can configure auth at the server or per app:
  • Server‑level auth: a default provider for all apps (only when splitByApp: false).
  • App‑level auth: each app defines its own provider; required when splitByApp: true.
With splitByApp: true, FrontMCP mounts each app at its own base path (for example /billing) and reuses that scope for OAuth issuers and the /message SSE endpoint so clients automatically target the right app.
Auth drives session creation, token propagation, and optional consent for tools/resources/prompts.
If an external provider doesn’t support Dynamic Client Registration (DCR), FrontMCP can front it with a local OAuth proxy that registers/holds the client on your behalf. See Remote OAuth → Proxy.

​
Where to configure auth

Server (multi‑app, shared auth): 
@FrontMcp({
  info: { name: 'Expense', version: '1.0.0' },
  apps: [BillingApp, AnalyticsApp],
  auth: { type: 'remote', name: 'frontegg', baseUrl: 'https://idp.example.com' },
})
export default class Server {}
Per app (isolated scopes): 
@App({ name: 'Billing', auth: { type: 'local', id: 'local', name: 'Local Auth' } })
export default class BillingApp {}

@FrontMcp({ info: { name: 'Suite', version: '1.0.0' }, apps: [BillingApp, AnalyticsApp], splitByApp: true })
export default class Server {}
Enable consent to let users select the tools/resources/prompts they grant, producing a scoped token. 
auth: {
    type: 'remote',
    name: 'frontegg',
    baseUrl: 'https://idp.example.com',
    consent: true
}
You can still send classic OAuth scopes via scopes: string[].

​
Sessions & transport

Auth integrates with server sessions (see Server Overview → Sessions):
  • session.sessionMode: stateful keeps tokens server‑side (recommended for nested providers); stateless embeds in JWT (simpler).
  • session.transportIdMode: uuid (per‑node) or jwt (signed transport IDs for distributed setups).
Use stateful sessions when working with short‑lived upstream tokens—you’ll get refresh without round‑trips.

​
Discovery & well‑known

Remote providers typically self‑describe via /.well-known/oauth-authorization-server and /.well-known/jwks.json. You may override endpoints and JWKS inline when needed.