feat(auth): add authplaneProvider

[muralx]

Adds a branded authplaneProvider preset alongside the existing providers, plus a runnable example, docs and a showcase entry. Configuration only, with no additional dependencies.

Contents

packages/core/src/server/auth/providers/authplane.ts	the preset
packages/core/src/server/auth/providers/authplane.test.ts	19 tests
packages/core/src/server/index.ts	export
examples/auth-authplane/	runnable example, plus an optional dev-authserver.sh helper
docs/api-reference/authplane-provider.mdx, docs/examples/auth-authplane.mdx, docs/guides/auth-providers.mdx, docs/docs.json	reference page, example page, provider guide section, nav
README.md, docs/images/showcase-authplane.png	showcase row

API

oauth: await authplaneProvider({
  issuer: process.env.AUTHPLANE_ISSUER,
  resource: process.env.SERVER_URL,
})

issuer is the authorization server's issuer identifier. resource is this server's resource identifier (RFC 9728 §1.2) — the public URL clients reach, advertised in its protected-resource metadata — and it also supplies the expected token audience. audience is available for deployments that configure an explicit override.

resource is required, unlike the other providers. Authplane binds the access token's aud to the RFC 8707 resource parameter the client sends, and the client takes that value from the advertised metadata, so a single option supplies both the advertised identifier and the expected audience.

Resource identifiers are compared by exact string match, so the provider advertises the configured value verbatim and asks for it in the form it will be advertised. issuer and resource are both validated as absolute http(s) URLs with a host and no fragment, per RFC 8707 §2, synchronously at construction.

Dynamic Client Registration is supported natively, so clients register with Authplane directly.

Example

examples/auth-authplane follows the existing auth examples — the coffee shop finder with per-user favourites. It ships an optional dev-authserver.sh that runs an authorization server locally in Docker and configures it for the example: registers the protected resource, creates a demo user, and writes .env when absent. Re-running it is safe and it never overwrites an existing .env. Nothing in the example depends on it.

Verification

Unit: 383 tests across 53 files pass, biome ci clean across 167 files, repo-wide pnpm test:format exits 0, and the example typechecks and builds against a freshly built core.

End to end against a live Authplane authorization server:

• protected-resource metadata advertises the configured resource identifier unchanged, served at the RFC 9728 §3 well-known path
• unauthenticated requests to /mcp return 401 with a WWW-Authenticate challenge carrying resource_metadata
• dynamic client registration, PKCE, sign-in, consent and token issuance all succeed; the access token carries typ: at+jwt and an aud matching the advertised resource
• tools/list and tools/call succeed with a valid token, and a token issued for a different resource is rejected