The self-hosted authorization server for the Model Context Protocol.
One Go binary. AGPL-3.0. MCP Authorization spec 2025-11-25, end-to-end.
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.
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 \ -e AUTHPLANE_CLIENT_CREDENTIALS_ENABLED=true \ -e AUTHPLANE_DPOP_ENABLED=true \ -e AUTHPLANE_TOKEN_EXCHANGE_ENABLED=true \ -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.
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
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.
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
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) |
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 |
| Rust | roadmap | — | — |
| C# | roadmap | — | — |
| Java | 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.
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 (2025-11-25) 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 2025-11-25 | The contract MCP clients and servers expect: discovery endpoints, dynamic client registration, audience-bound tokens. 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. |
| Dynamic Client Registration (RFC 7591) | Clients register themselves at runtime — needed for MCP clients you don't pre-provision. Three security modes: open, approved-redirects, admin-only. |
| Client ID Metadata Documents (CIMD) | Auto-registration by fetching client metadata from the client's URL. The MCP-native way for agents to identify themselves without a registration round-trip. |
| 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. |
Status & roadmap
Authplane is in active development. v0.1.x is production-shaped — the OAuth core, MCP discovery, and audit log are spec-compliant and tested. A few things to set expectations:
- Rust, C#, and Java SDKs are on the roadmap; Go, TypeScript, and Python 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. - Multi-tenant isolation today means running separate instances per tenant. A first-class tenant abstraction is post-
v1.0. - Public dynamic-registration signup UI is not in
v0.1; Dynamic Client Registration works over HTTP today, a hosted signup page is a follow-up. - Helm chart (
charts/authplane) is atv0.1.0; tested for single-instance and basic HA, expect tuning for large fleets.
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.