Authplane MCPサーバー

Authplane

The self-hosted authorization server for the Model Context Protocol.

One Go binary. AGPL-3.0. MCP Authorization spec 2026-07-28, end-to-end.

New in v0.2.0 — MCP Authorization 2026-07-28. Client ID Metadata Documents on by default, RFC 9207 iss on every authorization response, Protected Resource Metadata served by the AS, authorization_grant_profiles_supported for Enterprise-Managed Authorization, application_type on registration — and DPoP, client credentials, token exchange and XAA enabled out of the box. Details and the breaking changes in the changelog.

v0.2.3 is a security and signing-key patch. Upgrade, and read its upgrade notes first: the Helm chart refuses multi-replica keyfile installs without persistence, admin key commands need the server's --config, and Vault Transit signing now uses its own credential.

AI coding agents: read AGENTS.md first — it has the deterministic workflow for adding Authplane to an existing MCP server, the SDK pins per stack, and the three byte-for-byte rules that cause >90% of invalid_token failures. If you're an agent operating from web docs (no clone), llms.txt is the same link map in the llmstxt.org convention.

Why Authplane

Building an MCP server is now a one-afternoon job. Securing it isn't. You need to issue tokens, validate them, federate to your existing IdP, and let agents act on each other's behalf without losing the user behind the chain. Authplane is the one piece of infrastructure that answers all of that.

• Spec-compliant access tokens for any MCP server in any language — discovery, scopes, audience binding, refresh rotation, in token formats your existing resource servers already understand.
• Federation to your existing IdP — Google, Okta, Azure AD, Auth0, anyone OIDC-compliant. Authplane handles the OAuth side; you keep the access policy.
• Agent-to-agent delegation — one agent calls another on a user's behalf, with every hop recorded as an act-claim chain in the issued token and the audit log.
• Upstream provider vaulting — store GitHub / Google / Slack / Linear refresh tokens encrypted at rest and vend fresh access tokens via RFC 8693, with per-user / per-agent / per-resource consent enforced at every hop.
• DPoP proof-of-possession — bind tokens to a client-held key so a leaked token can't be replayed from another machine.
• Built-in Admin UI — React dashboard embedded in the same binary. No separate frontend, no extra container.
• Production storage and observability — PostgreSQL with cross-instance LISTEN/NOTIFY, OpenTelemetry traces and metrics, Prometheus, Helm chart, Vault Transit for HSM-grade signing.
• Zero-config dev — default SQLite, auto-generated signing keys, sensible defaults.

(Full RFC inventory at the bottom — Standards & Specifications.)

Quick Start

One docker run. A working OAuth 2.1 + MCP authorization server in under a minute.

export AUTHPLANE_ADMIN_API_KEY="$(openssl rand -hex 32)"
export AUTHPLANE_SESSION_SECRET="$(openssl rand -hex 32)"
echo "Save this — it's your Admin UI login: $AUTHPLANE_ADMIN_API_KEY"

docker run -p 9000:9000 -p 9001:9001 \
  -e AUTHPLANE_ADMIN_API_KEY \
  -e AUTHPLANE_SESSION_SECRET \
  -v authserver-data:/data \
  authplane/authserver:latest serve

Open http://localhost:9001/admin/ui/ and paste the printed API key. The public OAuth endpoints are on http://localhost:9000. Client credentials, token exchange, DPoP and CIMD are on out of the box — nothing to enable before your first MCP server can get a token.

Next: register your first MCP server

• Writing an MCP server from scratch? Start at the runnable example for your language — Python · TypeScript · Go. Auth in 5 lines, end-to-end smoke in make verify.
• Adding auth to an MCP server you already have? The retrofit example is a runnable before/after pair — same three tools in two versions, side-by-side, with a smoke-test that proves before accepts anything and after enforces auth. Python · TypeScript · Go. Or read the Connect an MCP Server guide for the prose version.
• Already have an MCP server running elsewhere? To point this AS at your server and drive the whole OAuth flow by hand with curl — no SDK, no compose — see Run the AS standalone and point it at your own MCP server. It also reconciles this Quick Start's config with the examples/ .env style.
• Operator quickstart (upstream providers, PostgreSQL, OIDC federation, Helm, multi-instance): docs/README.md.
• Building from source: CONTRIBUTING.md.

The Admin UI

Manage everything from a browser. The Admin UI is embedded in the same binary; every operation is also exposed via the Admin REST API.

SDKs

Authserver is only half the story. The MCP server on the other side still has to validate the tokens, expose the discovery endpoint, enforce scopes per tool, handle DPoP, and decode consent errors. The Authplane SDKs do all of that in 5 lines of integration code — measured, CI-counted, in Python / TypeScript / Go alike. The full ladder (basic MCP server → calling another resource → DPoP + per-tool scopes → fronting a Broker upstream) sits between 5 and 30 lines of auth-specific code per tier; see examples/ for the numbers under each tier's banner.

Every Authplane SDK provides the same baseline:

• JWT validation against the authserver JWKS, with caching
• Scope enforcement, per route or per tool
• The Protected Resource Metadata document at /.well-known/oauth-protected-resource/<mcp-path> (RFC 9728, suffixed per the MCP spec)
• DPoP proof verification (RFC 9449)
• A full OAuth client — Client Credentials, RFC 8693 Token Exchange, Introspection, Revocation
• Structured ConsentRequiredError decoding for the upstream-provider Broker flow

Pick the language and the framework adapter that match the stack you're already on.

Language	Repo	Integration Adapters	Docs
Go	authplane/go-sdk	✓ Official MCP Go SDK (go-sdk/mcp)✓ mark3labs/mcp-go (go-sdk/mark3labs)	README
TypeScript	authplane/ts-sdk	✓ Official MCP TypeScript SDK (@authplane/mcp)✓ FastMCP (@authplane/fastmcp)	README
Python	authplane/python-sdk	✓ Official MCP Python SDK (authplane-mcp)✓ FastMCP (authplane-fastmcp)	README
Java	authplane/java-sdk	✓ Official MCP Java SDK (authplane-mcp)✓ Spring Boot (authplane-spring)	README
C#	authplane/cs-sdk	✓ Official MCP C# SDK on ASP.NET Core (Authplane.Mcp)	README
Rust	ready to ship — see ROADMAP.md	—	—

Working examples wired against authserver live under examples/ — Python / TypeScript / Go, with four tiers each (basic MCP server, calling another resource, DPoP + per-tool scopes, MCP server fronting a Broker). Every example's make verify is exercised by make docs-smoke and the per-tier LOC budget is CI-enforced via tools/loccount.

Integration walkthroughs: Auth Client · Resource Server.

Documentation

For advanced operations and deeper reference, the docs/ tree is organized by audience:

Get started	Quickstart
Configuration	Configuration Guide · Schema Reference
API Reference	HTTP API (all endpoints) · CLI · Audit Events · Metrics
Security	Threat Model · Tokens and Claims · Key Rotation · DPoP
Deployment	Docker Compose · systemd · Kubernetes
Guides	Connect an MCP Server · Admin CLI & API · OIDC Federation · Observability
Grant Types	Client Credentials · Token Exchange · JWT Bearer / XAA · Enterprise-Managed Auth
Architecture	Architecture Overview · Authentication Flows · RFC Compliance
Full Index	Documentation Index

Standards & Specifications

Authplane implements the MCP Authorization specification (2026-07-28) and the OAuth 2.1 ecosystem standards behind it. ("OAuth 2.1" is an active IETF Internet-Draft, not a finalized RFC — the MCP spec itself targets it. See Compliance for the full picture.) Here's what each one gives you, in operator terms:

Standard	What it provides
MCP Authorization 2026-07-28	The contract MCP clients and servers expect: discovery endpoints, CIMD and dynamic client registration, audience-bound tokens, iss-stamped authorization responses. The reason your existing MCP tooling can find and talk to authserver without custom adapters.
OAuth 2.1	The base authorization flow — authorize endpoint, token endpoint, refresh tokens, scopes. PKCE-S256 is mandatory; the older insecure flows aren't supported.
PKCE (RFC 7636)	Prevents stolen authorization codes from being redeemed. Critical for public clients (CLIs, desktop apps, mobile).
DPoP (RFC 9449)	Binds tokens to a client-held key. A leaked token can't be replayed from another machine.
Resource Indicators (RFC 8707)	Audience-binds every token to a specific resource URI. An access token for one MCP server can't be replayed against another.
Protected Resource Metadata (RFC 9728)	MCP servers advertise where their authorization server lives. Clients discover the AS automatically.
Client ID Metadata Documents (CIMD)	The MCP-native way for a client with no prior relationship to identify itself: it hosts its metadata at an HTTPS URL and uses that URL as its client_id. No registration round-trip, no server-side record. Enabled by default, and the mechanism MCP 2026-07-28 asks clients to prefer.
Dynamic Client Registration (RFC 7591)	Clients register themselves at runtime. Deprecated by MCP 2026-07-28 in favor of CIMD, and retained for clients that do not support CIMD yet. Three security modes: open (default), approved-redirects, admin-only — see the note below.
OAuth AS Metadata (RFC 8414) + OIDC Discovery	The /.well-known/oauth-authorization-server and /.well-known/openid-configuration documents every OAuth client knows how to fetch.
Token Exchange (RFC 8693)	Delegated identity — one client mints a narrower or differently-scoped token from an existing one. Powers the agent-to-agent delegation chain and the upstream-provider Broker flow.
JWT Bearer (RFC 7523)	Trusted external IdPs assert identity directly into Authplane. The foundation for Cross-App Access (XAA) and enterprise federation.
JWT Access Tokens (RFC 9068)	Default token format (at+jwt). Every token is a self-contained JWT your resource servers can verify offline against the JWKS.
Token Introspection (RFC 7662)	Runtime token validation endpoint for revocation-aware verification.
Token Revocation (RFC 7009)	Standard endpoint to revoke refresh tokens and their families.

Roadmap

What is coming after v0.2.0, staged by how far along it is: ROADMAP.md.

A note on dcr.mode

dcr.mode defaults to open, which means any unauthenticated caller can register a client. The client_name it supplies is rendered on the consent screen a user is asked to trust.

That default exists for a historical reason: until recently, RFC 7591 was the only way a client with no prior relationship could obtain a client_id. MCP 2026-07-28 replaces that role with CIMD, which needs no registration endpoint and is enabled here by default — so most deployments no longer need open DCR for anything, and the server logs a warning at boot while it is active.

Clients choose a registration mechanism in this priority order, per the specification:

1. Pre-registered credentials, if the client has them
2. CIMD, when the AS advertises client_id_metadata_document_supported — which this server does
3. Dynamic Client Registration, when the AS advertises a registration_endpoint
4. Prompt the user

If your clients register via CIMD or are pre-provisioned, set dcr.mode: admin_only (or approved_redirects) and close the endpoint. It is left open by default only because client-side CIMD support is still arriving, and flipping it would break deployments whose clients register via DCR today.

If something here blocks your deployment, open an issue — the priority list is informed by what you're trying to ship.

License

AGPL-3.0-or-later — see LICENSE.

Need a different licence?

We'd love to hear from you — write to hello@authplane.ai and let's find one that fits.