frontmcp-authorities

name	frontmcp-authorities
description	Use when implementing authorization and access control for FrontMCP tools, resources, prompts, or skills, deciding who may invoke what. Covers the RBAC, ABAC, and ReBAC models and when to choose each; JWT claims mapping per identity provider (Auth0, Keycloak, Okta, Cognito, Frontegg); reusable named authority profiles; and custom authority evaluators for domain-specific policy. This is about who-can-do-what (permissions, roles, scopes), distinct from configuring auth modes and login (see frontmcp-config) and custom login UI (see frontmcp-auth-ui). Triggers: authorization, access control, RBAC, ABAC, ReBAC, permissions, roles, scopes, policy enforcement, JWT claims, restrict who can call a tool.
tags	["authorization","rbac","abac","rebac","security","permissions","roles","access-control","authorities","jwt"]
category	development
targets	["all"]
bundle	["full"]
priority	9
visibility	both
license	Apache-2.0
metadata	{"docs":"https://docs.agentfront.dev/frontmcp/authentication/authorities"}

FrontMCP Authorities

Built-in RBAC/ABAC/ReBAC authorization system for FrontMCP entry types. Each flow has native checkEntryAuthorities and filterByAuthorities stages that enforce access control policies declared via the authorities field on entry decorators. Configured via @FrontMcp({ authorities: { claimsMapping, profiles, scopeMapping } }) — no plugin needed. Flow stages handle enforcement, and developers can hook into them with Will, Did, and Around decorators. Supports named profiles for reuse, JWT claims mapping for any identity provider, inline policies with roles/permissions/attributes/relationships, and composable combinators (allOf, anyOf, not).

When to Use This Skill

Must Use

• Adding role-based or permission-based access control to tools, resources, prompts, or skills
• Restricting MCP entry visibility based on the caller's JWT claims
• Enforcing tenant isolation (ABAC) or relationship checks (ReBAC) on entries
• Gating which skills a caller can discover and load (@Skill({ authorities }))

Recommended

• Setting up a multi-tenant server where different tenants see different tools
• Building an admin vs. user distinction across your MCP surface
• Combining multiple authorization models (e.g., RBAC + ABAC) on the same entry

Skip When

• You only need authentication (login/token validation) without authorization (see frontmcp-config / configure-auth)
• You are building a public server with no access restrictions (use mode: 'public')
• You need OAuth scopes at the transport level, not entry-level policies (see configure-auth-modes)

Decision: Use this skill whenever you need to control who can access which entries based on roles, permissions, attributes, or relationships.

CRITICAL: Ask About JWT Shape First

Before writing any authorities configuration, the coding agent MUST ask the developer:

"What identity provider (IdP) are you using, and what does your JWT payload look like? I need to know where roles, permissions, and tenant ID are located in the claims."

Why this matters: Every IdP places roles and permissions in different JWT claim paths. Auth0 uses namespaced URIs (), Keycloak nests them under , Okta uses , Cognito uses , and Frontegg uses flat /. Writing without knowing the actual token shape will produce silent authorization failures where every user is denied.