Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.agentfront.dev/llms.txt

Use this file to discover all available pages before exploring further.

Overview

import { AuthRegistry } from '@frontmcp/sdk';

// Access via scope
const auth = scope.authProviders;

// Get primary auth provider
const primary = auth.getPrimary();

// Get all auth providers
const providers = auth.getAuthProviders();

Methods

getPrimary()

Get the primary auth provider.
getPrimary(): FrontMcpAuth
Example:
const auth = registry.getPrimary();

// Provider identity / mode-derived metadata
console.log(auth.id);        // e.g. 'github_com'
console.log(auth.issuer);    // OAuth issuer URL when applicable

// Validate an incoming HTTP request (throws on failure)
await auth.validate(serverRequest);

// Authenticated outbound fetch through the active provider
const res = await auth.fetch('https://api.example.com/me');

getAuthProviders()

Get all auth provider entries.
getAuthProviders(): ReadonlyArray<AuthProviderEntry>
Example:
const providers = registry.getAuthProviders();
for (const provider of providers) {
  console.log(`Provider: ${provider.name} (${provider.mode})`);
}

Auth Modes

FrontMCP supports four authentication modes:

Public

mode: 'public' — no authentication

Transparent

mode: 'transparent' — pass-through tokens validated against upstream JWKS

Local

mode: 'local' — built-in OAuth 2.1 authorization server

Remote

mode: 'remote' — OAuth 2.1 server proxying to an upstream IdP
See the Authentication overview for full mode semantics. The registry exposes requiresOrchestration (true for local/remote) so adapters know whether to mount OAuth routes.

Properties

requiresOrchestration

Whether the current configuration requires orchestration.
if (registry.requiresOrchestration) {
  // Setup OAuth callbacks, session management, etc.
}

detection

Auth provider detection result across apps in scope.
interface AuthProviderDetectionResult {
  /** Map of providerId -> DetectedAuthProvider (mode, scopes, appIds, etc.) */
  providers: Map<string, DetectedAuthProvider>;
  /** True when local/remote mode requires the OAuth orchestration routes */
  requiresOrchestration: boolean;
  /** Provider id at the parent scope (if any) */
  parentProviderId?: string;
  /** Provider ids contributed only by child apps */
  childProviderIds: string[];
  /** Number of distinct providers */
  uniqueProviderCount: number;
  /** Configuration validation errors */
  validationErrors: string[];
  /** Non-fatal warnings */
  warnings: string[];
}

Auth Provider Detection

The registry detects auth requirements across the scope hierarchy:
// Check detection result
const detection = registry.detection;

if (detection.uniqueProviderCount > 0) {
  for (const [id, provider] of detection.providers) {
    console.log(`${id}: mode=${provider.mode} apps=[${provider.appIds.join(', ')}]`);
  }
}

if (registry.requiresOrchestration) {
  // Mount OAuth routes
}

Auth in Context Classes

Context classes that extend ExecutionContextBase expose two auth surfaces:
@Tool({ name: 'protected_tool', inputSchema: {} })
class ProtectedTool extends ToolContext {
  async execute() {
    // Typed FrontMcpAuthContext (roles, permissions, claims, scopes)
    if (!this.auth.hasRole('admin')) throw new Error('Admin required');
    const tenantId = this.auth.claims['tenantId'];

    // Raw token (Partial<AuthInfo>) for outbound API calls
    const token = this.context.authInfo?.token;
  }
}

Configuration Validation

The registry validates auth configuration:
// Invalid configuration throws
@FrontMcp({
  auth: {
    mode: 'local',
    providers: [], // Error: No providers specified
  },
})
class InvalidServer { }

FrontMcpAuth API

The primary auth provider is an abstract base class:
abstract class FrontMcpAuth<Options extends AuthOptions = AuthOptions> {
  /** Promise resolved when the provider has finished initializing. */
  ready: Promise<void>;
  /** Parsed auth options (mode, providers, etc.). */
  readonly options: Options;
  /** Stable provider ID derived from options. */
  readonly id: string;

  /** Authenticated outbound fetch (mode-specific implementation). */
  abstract fetch(input: RequestInfo | URL, init?: RequestInit): Promise<Response>;

  /** Validate an incoming server request — throws if not authenticated. */
  abstract validate(request: ServerRequest): Promise<void>;

  /** OAuth issuer URL (when applicable). */
  abstract get issuer(): string;
}
For request-scoped role/permission/scope checks, use this.auth (a FrontMcpAuthContext) inside execution contexts — see the section below.

Session Integration

Auth integrates with session management:
@FrontMcp({
  auth: {
    mode: 'local',
    sessionStore: {
      provider: 'redis',
      host: 'localhost',
      keyPrefix: 'auth:session:',
    },
  },
})
class SecureServer { }

Multi-App Auth

When multiple apps have different auth requirements:
@FrontMcp({
  name: 'server',
  apps: [PublicApp, ProtectedApp],
})
class MultiAuthServer { }

// The registry detects mixed auth providers across nested apps
const detection = scope.authProviders.detection;
// detection.providers is a Map<string, DetectedAuthProvider>
const providerIds = Array.from(detection.providers.keys());
// e.g. ['public', 'auth_example_com']
for (const provider of detection.providers.values()) {
  // provider.mode is one of 'public' | 'transparent' | 'local' | 'remote'
  console.log(`${provider.id} -> ${provider.mode} (apps=[${provider.appIds.join(', ')}])`);
}

FrontMcpAuthContext

The FrontMcpAuthContext is a request-scoped auth identity object available inside tool, resource, and prompt execution. It provides role, permission, and scope checks extracted from JWT claims.
import type { FrontMcpAuthContext } from '@frontmcp/auth';

Properties

PropertyTypeDescription
userFrontMcpAuthUserResolved user identity (sub, name, email, picture)
isAnonymousbooleanTrue when sub starts with anon: or is empty
modestringAuthentication mode (public, transparent, local, remote)
sessionIdstringSession identifier (empty string if no session)
scopesreadonly string[]OAuth scopes granted to this session
claimsReadonly<Record<string, unknown>>Raw JWT claims
rolesreadonly string[]Resolved roles (via claimsMapping or direct extraction)
permissionsreadonly string[]Resolved permissions (via claimsMapping or direct)

Methods

MethodSignatureDescription
hasRole(role: string) => booleanCheck if user has a specific role
hasAllRoles(roles: readonly string[]) => booleanCheck if user has ALL specified roles
hasAnyRole(roles: readonly string[]) => booleanCheck if user has at least one role
hasPermission(permission: string) => booleanCheck if user has a specific permission
hasAllPermissions(permissions: readonly string[]) => booleanCheck if user has ALL specified permissions
hasAnyPermission(permissions: readonly string[]) => booleanCheck if user has at least one permission
hasScope(scope: string) => booleanCheck if session has a specific OAuth scope
hasAllScopes(scopes: readonly string[]) => booleanCheck if session has ALL specified scopes
hasAnyScope(scopes: readonly string[]) => booleanCheck if session has at least one scope

Extension

Add custom typed fields via global interface augmentation:
declare global {
  interface ExtendFrontMcpAuthContext {
    tenantId: string;
    orgName: string;
  }
}
Custom fields are populated by AuthContextPipe functions registered in your server config.
FrontMcpAuthContext vs Authorization: FrontMcpAuthContext is request-scoped and provides roles, permissions, and scopes from JWT claims. The Authorization interface is transport-scoped and tracks authorized tools, prompts, apps, and provider tokens. Use FrontMcpAuthContext for role/permission checks; use Authorization for tool/app access control.