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
isson every authorization response, Protected Resource Metadata served by the AS,authorization_grant_profiles_supportedfor Enterprise-Managed Authorization,application_typeon registration — and DPoP, client credentials, token exchange and XAA enabled out of the box. Details and the breaking changes in the changelog.
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_tokenfailures. If you're an agent operating from web docs (no clone), llms.txt is the same link map in the llmstxt.org convention.
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.)
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 serveOpen 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.
- 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
beforeaccepts anything andafterenforces 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 theexamples/.envstyle. - Operator quickstart (upstream providers, PostgreSQL, OIDC federation, Helm, multi-instance):
docs/README.md. - Building from source: CONTRIBUTING.md.
Manage everything from a browser. The Admin UI is embedded in the same binary; every operation is also exposed via the Admin REST API.
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
ConsentRequiredErrordecoding 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 | roadmap | — | — |
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.
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 |
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. |
Authplane is in active development. v0.2.x is production-shaped — the OAuth core, MCP discovery, and audit log are spec-compliant and tested. A few things to set expectations:
- The Rust SDK is on the roadmap; Go, TypeScript, Python, Java, and C# are released.
- Upstream-provider connections (Broker flow) require manual configuration of at-rest encryption (
aes_masteror HashiCorp Vault Transit) before they activate — covered indocs/guides/upstream-providers/connecting-providers.md. - Isolating separate customers or environments today means running separate instances. A first-class abstraction for it is post-
v1.0. - Public dynamic-registration signup UI is not in
v0.2; Dynamic Client Registration works over HTTP today, a hosted signup page is a follow-up. - Helm chart (
charts/authplane) is atv0.4.0; tested for single-instance and basic HA, expect tuning for large fleets.
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:
- Pre-registered credentials, if the client has them
- CIMD, when the AS advertises
client_id_metadata_document_supported— which this server does - Dynamic Client Registration, when the AS advertises a
registration_endpoint - 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.
AGPL-3.0-or-later — see LICENSE.
We'd love to hear from you — write to hello@authplane.ai and let's find one that fits.