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
Property Type Description 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
Method Signature Description 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.