@frontmcp/skills 1.5.3 → 1.5.4

package/catalog/frontmcp-config/examples/configure-auth-modes/local-dcr-control.md

@@ -54,6 +54,13 @@ To keep DCR open but authenticated instead of closed, drop `enabled: false` and
 `Authorization: Bearer <token>` header that matches it (constant-time compared), and
 requests without it get `401 invalid_token`.
 
+`dcr.maxDynamicClients` (default `1000`) caps how many dynamically-registered clients
+are kept in memory: once the cap is reached, further DCR registrations are **rejected**
+(`503 temporarily_unavailable`) rather than evicting an existing client, so already-registered
+clients — including confidential ones — are preserved. Pre-registered `dcr.clients` never
+count toward it, and `0` disables dynamic registration entirely. This bounds memory growth
+from unauthenticated DCR (pair it with `initialAccessToken` for authenticated admission).
+
 ## What This Demonstrates
 
 - Setting `dcr.enabled: false` so `POST /oauth/register` returns 404 and `registration_endpoint` is dropped from AS metadata

package/catalog/frontmcp-config/examples/configure-auth-modes/transparent-jwt-validation.md

@@ -8,6 +8,7 @@ features:
   - "Using `mode: 'transparent'` to validate tokens from an external identity provider"
   - 'Setting `expectedAudience` to restrict which tokens are accepted'
   - 'The server fetches JWKS from `{provider}/.well-known/jwks.json` automatically'
+  - 'Issuer (`iss`) is validated against `provider` by default; opt out or extend with `providerConfig.verifyIssuer` / `additionalIssuers`'
 ---
 
 # Transparent JWT Validation
@@ -56,6 +57,37 @@ class Server {}
 - Using `mode: 'transparent'` to validate tokens from an external identity provider
 - Setting `expectedAudience` to restrict which tokens are accepted
 - The server fetches JWKS from `{provider}/.well-known/jwks.json` automatically
+- Issuer (`iss`) is validated against `provider` by default; opt out or extend with `providerConfig.verifyIssuer` / `additionalIssuers`
+
+## Claim validation
+
+A valid JWKS signature only proves the IdP signed the token — not that it was
+minted for this server. Because every service behind the same IdP shares the
+signing keys, transparent mode also validates two claims:
+
+- **Issuer (`iss`)** — validated against `provider` by default (matched with or
+  without a trailing slash). Add trusted extras with
+  `providerConfig.additionalIssuers: ['https://gateway.example']`. To turn the
+  check off for a trusted gateway whose re-minted issuer you cannot enumerate,
+  set `providerConfig.verifyIssuer: false` — and keep a strict `expectedAudience`
+  when you do.
+- **Audience (`aud`)** — when the token carries one, it must match
+  `expectedAudience`. Tokens without an `aud` are accepted for IdP
+  compatibility; set `expectedAudience` and issue audience-bound tokens for the
+  strictest posture.
+
+```typescript
+auth: {
+  mode: 'transparent',
+  provider: 'https://auth.example.com',
+  expectedAudience: 'my-api',
+  providerConfig: {
+    // trust one extra issuer (e.g. a gateway that re-mints tokens)
+    additionalIssuers: ['https://gateway.example'],
+    // verifyIssuer: false, // ⚠️ disables the iss check entirely — last resort
+  },
+}
+```
 
 ## Related
 

package/catalog/frontmcp-config/references/configure-auth-modes.md

@@ -39,6 +39,8 @@ auth: {
 
 > Transparent also accepts `allowAnonymous` (default `false`) + `anonymousScopes` (default `['anonymous']`) to admit tokenless requests as anonymous, and `requiredScopes` to reject tokens missing a scope. `expectedAudience` is shared across transparent/local/remote, not transparent-only.
 
+> **Claim validation (transparent):** a valid JWKS signature alone does not bind a token to this server — every service behind the same IdP shares the signing keys. FrontMCP therefore validates the token `iss` against `provider` (plus any `providerConfig.additionalIssuers`, each matched with/without a trailing slash) **by default**, and validates `aud` against `expectedAudience` when the token carries one. This blocks replay of a token minted by the same IdP for a different issuer or audience. Set `providerConfig.additionalIssuers: ['https://gateway.example']` to trust a known extra issuer. `providerConfig.verifyIssuer: false` **disables the issuer check entirely** (accepts any issuer signed by the JWKS) — only for a trusted gateway whose re-minted issuer you cannot enumerate, and always paired with a strict `expectedAudience`.
+
 ## Local Mode
 
 Built-in OAuth 2.1 server that signs its own JWT tokens. Full control over token lifecycle.
@@ -61,6 +63,10 @@ Signing is **HS256 with a symmetric `JWT_SECRET`** (no key pair). Set a stable `
 
 Local mode also accepts `allowDefaultPublic` (default `false` — set `true` to admit tokenless requests as anonymous instead of returning 401), `anonymousScopes` (default `['anonymous']` — scopes for those anonymous sessions), and `expectedAudience` (reject tokens minted for a different `aud`).
 
+> **Client registration (security):** by default an unregistered `client_id` is accepted with whatever `redirect_uri` it presents. Set `requireRegisteredClients: true` (local/remote) to require every client to be registered (DCR / `dcr.clients`) or a CIMD client-id URL, so `redirect_uri` is exact-matched (OAuth 2.1) — this prevents auth-code interception via an attacker-chosen redirect. Confidential clients (`token_endpoint_auth_method: client_secret_basic`/`client_secret_post`) are authenticated with a constant-time `client_secret` check on both the code-exchange and refresh grants (Basic header or body param).
+
+> **Public origin (security):** pin `FRONTMCP_PUBLIC_URL` in production. The issuer / resource / OAuth-discovery URLs and the transparent expected audience derive from it rather than from request headers; `X-Forwarded-Host`/`X-Forwarded-Proto` are ignored unless `FRONTMCP_TRUST_PROXY=1` (a trusted proxy that strips client-supplied forwarded headers).
+
 **Progressive / incremental authorization** (opt-in via `incrementalAuth`): when enabled, the minted token carries an `authorized_apps` claim and a `tools/call` for an app NOT in that claim resolves to a `CallToolResult` with `isError: true` and `_meta.code === 'AUTHORIZATION_REQUIRED'` (fields: `authorization_required: true`, `app`, `tool`, `auth_url`, `required_scopes`, `session_mode`, `supports_incremental`). The client declares the initial grant on `/oauth/authorize?…&apps=crm` (omit `apps` to grant all apps) and expands it later via an incremental authorize `…&mode=incremental&app=slack&apps=crm` — the new token's claim is the **union** of the prior apps plus the target (the user identity and already-granted apps are preserved; upstream tokens stay server-side). Without an `incrementalAuth` block, no claim is minted and there is **no** app-level gating (allow-all preserved). `consent` (tool-level) and `incrementalAuth` (app-level) are independent.
 
 To collect and verify your own credentials, add a declarative `login` (custom page fields / title / subject strategy) and an `authenticate(input, ctx)` verifier that returns `{ ok: true, sub?, claims? }` (custom claims are embedded in the token; reserved claims are stripped) or `{ ok: false, message }` (re-renders the login page; no code issued). Both are optional and default to the built-in email login. See `configure-auth.md` for a full example.

package/catalog/frontmcp-production-readiness/references/common-checklist.md

@@ -18,6 +18,9 @@ These checks apply to ALL deployment targets. Run them first, then proceed to yo
 - [ ] Session TTL is configured appropriately (not infinite)
 - [ ] Tool-level authorization is enforced where needed (ApprovalPlugin or custom)
 - [ ] OAuth redirect URIs are restricted to known domains
+- [ ] `FRONTMCP_PUBLIC_URL` is pinned to the canonical origin — issuer / resource / OAuth-discovery URLs and the transparent-mode expected audience derive from it, not from request headers. `X-Forwarded-Host`/`X-Forwarded-Proto` are ignored by default; only set `FRONTMCP_TRUST_PROXY=1` behind a proxy that strips client-supplied forwarded headers
+- [ ] `auth.requireRegisteredClients: true` (local/remote) so unknown clients can't present an attacker-chosen `redirect_uri` (auth-code interception). Clients register via DCR / `dcr.clients` / CIMD
+- [ ] Transparent mode sets `auth.expectedAudience` (bind tokens to this resource) and validates issuer (`providerConfig.verifyIssuer`, default on)
 
 ### CORS Configuration
 

package/catalog/skills-manifest.json

@@ -630,7 +630,8 @@
               "features": [
                 "Using `mode: 'transparent'` to validate tokens from an external identity provider",
                 "Setting `expectedAudience` to restrict which tokens are accepted",
-                "The server fetches JWKS from `{provider}/.well-known/jwks.json` automatically"
+                "The server fetches JWKS from `{provider}/.well-known/jwks.json` automatically",
+                "Issuer (`iss`) is validated against `provider` by default; opt out or extend with `providerConfig.verifyIssuer` / `additionalIssuers`"
               ]
             }
           ]

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@frontmcp/skills",
-  "version": "1.5.3",
+  "version": "1.5.4",
   "description": "Curated skills catalog for FrontMCP projects",
   "author": "AgentFront <info@agentfront.dev>",
   "homepage": "https://docs.agentfront.dev",