Introduction

TL;DR — AuthPlane is the authorization layer for the Model Context Protocol. It ships as a self-hosted OAuth 2.1 authorization server (a managed cloud offering is on the way) that runs alongside your MCP server and owns the entire token path, so your server just validates JWTs locally. These docs cover a runnable Quickstart, the concepts you need before configuring, per-SDK guides, deployment topologies, and every reference you’ll want.

What AuthPlane is

AuthPlane is a complete OAuth 2.1 authorization server for the Model Context Protocol — token issuance, discovery, IdP federation, delegation, upstream-token vault, agent identity, and an admin UI — shipped today as one self-contained binary you run next to your MCP server, with a managed cloud offering (same product, same guarantees) landing shortly.

Concretely, AuthPlane owns everything the MCP authorization spec asks for: it tells the client where to send the user for consent, mints access tokens bound to a specific resource server, and enforces proof-of-possession on every call. It holds the OAuth endpoints (/oauth/authorize, /oauth/token, /oauth/register, /oauth/revoke, /oauth/introspect), signs the tokens, and publishes the metadata your MCP clients discover. Your MCP server validates the tokens locally against the AuthPlane JWKS. No per-request round-trip. No library that owns your request handler.

The problem it solves

MCP puts an authorization layer between agents and the tools they call. The spec is a stack of RFCs — OAuth 2.1 (auth code + PKCE-S256), Dynamic Client Registration (RFC 7591), Protected Resource Metadata (RFC 9728), Resource Indicators (RFC 8707), DPoP proof-of-possession (RFC 9449), Token Exchange for delegation (RFC 8693), and more. Each one has to be implemented correctly and they all have to fit together coherently — the compliance surface is what makes this hard, not any single RFC.

You have two options:

  • Roll your own — implement 16 RFCs correctly, run the compliance test suites, keep up with revisions. Real cost measured in engineer-quarters.
  • Adopt AuthPlane — spec-compliant token issuance, purpose-built for MCP, licensed under AGPL-3.0. Deploy the self-hosted binary in your perimeter today, or move to the managed offering when it lands — the wire protocol is identical.

How AuthPlane fits into your stack

flowchart TD
    Client["MCP client<br/>(Claude, Cursor, Inspector)"]
    AS["AuthPlane AS<br/>:9000 · :9001"]
    MCP["Your MCP server + AuthPlane SDK<br/>· serves PRM (RFC 9728)<br/>· verifies JWTs locally"]

    Client -->|OAuth authorize / token| AS
    AS -->|access token| Client
    Client -->|bearer / DPoP proof| MCP
    MCP -->|"JWKS (cached by SDK)"| AS

The client discovers the protected-resource metadata (PRM) directly from your MCP server — the AuthPlane SDK serves the RFC 9728 document off your resource. The client then obtains a token from AuthPlane once. Your MCP server validates each incoming request against the JWKS the SDK caches from AuthPlane. Auth is out of band. Your request handler stays yours.

Your IdP (Google Workspace, Okta, Entra ID, Auth0, or any OIDC provider) still authenticates the humans — AuthPlane federates upstream to preserve that. What AuthPlane owns is agent-facing authorization: token issuance, scope enforcement, delegation via RFC 8693, sender-constrained tokens via RFC 9449, and the vault that holds refresh tokens for the third-party APIs your agents call.

How these docs are organized

Every page follows the same shape — TL;DR at the top, then What it does / When you need this / Quick start / How it works / Configuration reference / Troubleshooting / Related. You can drop in anywhere and know where you are.

  • Getting started — introduction (this page), Quickstart for the ten-minute run, Your first MCP server for what the SDK snippet actually does, Choose your topology to pick a deployment shape.
  • Concepts — the mental model before you touch config: architecture, resource servers and PRM, grants and flows, the token vault, delegation chains, DPoP, XAA, agent identity.
  • SDKs — one page per language (Python, TypeScript, Go), each covering the adapters for the major MCP frameworks.
  • Guides — task-focused, step-by-step: federate to your IdP, enable DPoP end-to-end, wire the token vault, set up XAA, monitor, admin API.
  • Deployment topologies — every deployment shape AuthPlane supports, with named-component diagrams and wire-level flow sequences.
  • Operate — Docker Compose, Kubernetes (Helm), standalone binary, Vault Transit signing, backup and upgrade.
  • Reference — configuration schema, OpenAPI specs, RFC compliance table, error catalog, metrics catalog, CLI reference.
  • Security — threat model, token design, DPoP deep-dive, key management, vulnerability reporting.
  • FAQ & Troubleshooting — common questions, debugging checklist, where to get help.

Where to start next

AuthPlane is at v0.1.x. It is validated end-to-end with Claude Desktop, Claude Code, and MCP Inspector; Cursor and VS Code support is tracked separately (see RFC compliance). It is not SOC 2 certified — self-hosted software is your organization’s certification. The code is AGPL-3.0 and reviewable; security disclosures go through GitHub Private Vulnerability Reporting (see Reporting vulnerabilities).