Authentication Overview

FrontMCP implements a flexible three-tier authentication system designed for both development simplicity and production security.

Authentication Modes

FrontMCP supports three authentication modes, each designed for different deployment scenarios:

Public Mode

No authentication required. Anonymous sessions are auto-generated for all requests.Best for: Development, testing, public APIs

Transparent Mode

Pass-through tokens from external identity providers. FrontMCP validates tokens against upstream JWKS.Best for: Existing Auth0, Okta, Azure AD integrations

Orchestrated Mode

Full OAuth 2.1 authorization server. Can be self-contained (local) or proxy to upstream IdP (remote).Best for: Multi-app scenarios, federated auth, progressive authorization

Quick Mode Selection

Scenario	Recommended Mode	Why
Local development	`public`	No setup required
Existing IdP (Auth0, Okta)	`transparent`	Direct token pass-through
Multi-provider federation	`remote`	Unified session, multiple IdPs
Self-contained auth	`local`	Full control, built-in OAuth server

Configuration Levels

Authentication can be configured at two levels:

Server Level
App Level

Apply the same auth configuration to all apps:

@FrontMcp({
  info: { name: 'MyServer', version: '1.0.0' },
  apps: [BillingApp, AnalyticsApp],
  auth: {
    mode: 'local',
    consent: { enabled: true },
  },
})
export class Server {}

Each app defines its own auth provider (required when splitByApp: true):

@App({
  name: 'Billing',
  auth: {
    mode: 'transparent',
    provider: 'https://auth.example.com',
  },
})
export class BillingApp {}

@FrontMcp({
  info: { name: 'Suite', version: '1.0.0' },
  apps: [BillingApp, CrmApp],
  splitByApp: true,
})
export class Server {}

When using splitByApp: true, you must configure auth per app. Server-level auth is not allowed.

OAuth 2.1 Compliance

FrontMCP’s orchestrated mode is fully OAuth 2.1 compliant:

PKCE Required - Only S256 code challenge method supported

Authorization Code Flow - No implicit or password grants

Refresh Token Rotation - Tokens rotate on each use

JWT Access Tokens - Signed with RS256 or ES256

Session Management

Sessions determine how tokens are stored and managed:

Session Mode	Token Storage	Refresh	Multi-Instance
Stateful	Server-side (Redis/memory)	Silent refresh	Requires shared storage
Stateless	Embedded in JWT	Client must re-auth	Works anywhere

Use stateful sessions when working with short-lived upstream tokens. You’ll get automatic refresh without client round-trips.

auth: {
  mode: 'local',
  tokenStorage: {
    redis: { host: 'localhost', port: 6379 },
  },
}

Discovery Endpoints

FrontMCP exposes standard OAuth discovery endpoints:

Endpoint	Description
`/.well-known/oauth-authorization-server`	OAuth 2.0 Authorization Server Metadata (RFC 8414)
`/.well-known/jwks.json`	JSON Web Key Set for token verification (RFC 7517)
`/.well-known/oauth-protected-resource`	Protected Resource Metadata

Next Steps

Authorization Modes

Deep dive into public, transparent, and orchestrated modes

Token & Sessions

Configure token lifetimes and session management

Remote OAuth

Connect to external identity providers

Production Checklist

Security requirements for production deployments

Get Started

FrontMCP

Features

Extensibility

Testing

React SDK

Guides

Authentication Overview

Authentication Modes

Public Mode

Transparent Mode

Orchestrated Mode

Quick Mode Selection

Configuration Levels

OAuth 2.1 Compliance

Session Management

Discovery Endpoints

Next Steps

Authorization Modes

Token & Sessions

Remote OAuth

Production Checklist

​Authentication Modes

Public Mode

Transparent Mode

Orchestrated Mode

​Quick Mode Selection

​Configuration Levels

​OAuth 2.1 Compliance

​Session Management

​Discovery Endpoints

​Next Steps

Authorization Modes

Token & Sessions

Remote OAuth

Production Checklist

Authentication Modes

Quick Mode Selection

Configuration Levels

OAuth 2.1 Compliance

Session Management

Discovery Endpoints

Next Steps