What is AuthPlane?
AuthPlane is the self-hosted authorization server for the Model Context Protocol. It ships as one Go binary — authserver — that implements OAuth 2.1 and the MCP Authorization spec (2025-11-25) end to end. You run it in your own infrastructure, next to your MCP servers.
The problem it solves
Section titled “The problem it solves”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 token exchange, 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 — a 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, a Helm chart, and HashiCorp Vault Transit for HSM-grade signing.
- Zero-config dev — SQLite by default, auto-generated signing keys, sensible defaults.
Mint or Broker — two modes per resource
Section titled “Mint or Broker — two modes per resource”For every resource (MCP server) you register, AuthPlane acts in one of two modes:
- Mint — AuthPlane is the issuer. It signs the JWT access token that your MCP server validates offline against the JWKS.
- Broker — AuthPlane stores upstream tokens (GitHub, Slack, Okta, …) encrypted at rest and vends them to your MCP server via RFC 8693 token exchange, gated by consent at every hop.
See How It Works for the full flow.
SDKs for the resource side
Section titled “SDKs for the resource side”The authorization server is only half the story. The MCP server on the other side still has to validate tokens, expose the discovery endpoint, enforce scopes per tool, handle DPoP, and decode consent errors. The AuthPlane SDKs do all of that in about 5 lines of integration code:
| Language | Package(s) | Adapters |
|---|---|---|
| Go | authplane/go-sdk | Official MCP Go SDK (go-sdk/mcp) |
| TypeScript | authplane/ts-sdk | Official MCP TypeScript SDK (@authplane/mcp), FastMCP (@authplane/fastmcp) |
| Python | authplane/python-sdk | Official MCP Python SDK (authplane-mcp), FastMCP (authplane-fastmcp) |
| Rust · C# · Java | roadmap | — |
Every SDK provides the same baseline: JWT validation against the authserver JWKS (with caching), scope enforcement per route or per tool, the RFC 9728 Protected Resource Metadata document, DPoP proof verification, a full OAuth client (client credentials, token exchange, introspection, revocation), and structured ConsentRequiredError decoding for the Broker flow.
On the client side, AuthPlane is tested against Claude Code, Claude Desktop, and MCP Inspector.
Standards, end to end
Section titled “Standards, end to end”AuthPlane implements the MCP Authorization specification (2025-11-25) and the OAuth 2.1 ecosystem standards behind it:
| Standard | What it provides |
|---|---|
| MCP Authorization 2025-11-25 | The contract MCP clients and servers expect: discovery, dynamic client registration, audience-bound tokens. |
| OAuth 2.1 | The base authorization flow. PKCE-S256 is mandatory; the older insecure flows aren’t supported. |
| PKCE (RFC 7636) | Prevents stolen authorization codes from being redeemed. |
| 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 one resource URI — a token for one MCP server can’t be replayed against another. |
| Protected Resource Metadata (RFC 9728) | MCP servers advertise where their authorization server lives. |
| Dynamic Client Registration (RFC 7591) | Runtime client registration, in three security modes: open, approved-redirects, admin-only. |
| Client ID Metadata Documents (CIMD) | Auto-registration by fetching client metadata from the client’s URL. |
| AS Metadata (RFC 8414) + OIDC Discovery | The /.well-known/oauth-authorization-server and /.well-known/openid-configuration documents. |
| Token Exchange (RFC 8693) | Delegated identity — powers agent-to-agent chains and the upstream-provider Broker flow. |
| JWT Bearer (RFC 7523) | Trusted external IdPs assert identity directly into AuthPlane (Cross-App Access / XAA). |
| JWT Access Tokens (RFC 9068) | Default token format (at+jwt) — verifiable offline against the JWKS. |
| Introspection (RFC 7662) · Revocation (RFC 7009) | Runtime token validation and standard revocation of refresh-token families. |
Full details in the RFC compliance reference and the upstream compliance matrix.
The Admin UI
Section titled “The Admin UI”Manage clients, users, resources, broker providers, signing keys, grants, and the audit log from a React console embedded in the same binary — no separate frontend to deploy. It listens on the admin port (http://localhost:9001/admin/ui/ in dev).
The product family
Section titled “The product family”- AuthPlane Auth Server — the open-source core documented on this site. One Go binary, licensed AGPL-3.0.
- AuthPlane EE — the self-hosted enterprise edition, under a commercial license.
- AuthPlane Cloud — the managed SaaS. Coming soon.
Need a different license for the open-source core? Write to hello@authplane.ai.