OAuth for MCP servers without building an auth server

The MCP authorization spec asks a remote server to behave like an OAuth 2.1 protected resource, backed by an authorization server that clients can discover and register with on their own. Building that yourself is a project. On DenkOps it is one line in denkops.json.

Free: 1 project, no credit card. 5 project slots €39/month, €5 per extra slot.

What the MCP spec expects from a protected server

When Claude, ChatGPT or another client connects to a protected MCP server, it walks a fixed chain:

The first unauthenticated request gets 401 with a WWW-Authenticate header that points to the server's protected resource metadata.
The client reads that metadata (RFC 9728) to find the authorization server.
It reads the authorization server metadata (RFC 8414) and registers itself, either through dynamic client registration or a client ID metadata document.
It runs an authorization code flow with PKCE (S256), the user signs in and consents, and the client receives a token scoped to your server's URL.
Every MCP request carries that token, and refresh tokens keep the session alive.

Miss one link and the client shows a vague "couldn't connect" error. The free MCP server checker walks the same chain and tells you which step fails.

What you would build yourself

An authorization server with registration, consent screens, PKCE verification, token issuance and refresh rotation, plus a sign-in provider integration, plus the metadata endpoints, plus a per-user allow list. Then you keep it patched.

What DenkOps gives you

Set "connector": true in denkops.json and deploy. DenkOps puts its own OAuth 2.1 authorization server in front of your MCP endpoint:

Discovery documents, dynamic client registration and client ID metadata documents.
Sign-in with Google, GitHub or Microsoft, or email and password for reviewer accounts.
An access policy per connector: public, or a list of allowed emails managed in the dashboard.
Your own icon and brand colours on the sign-in and consent pages.
Your server receives requests from signed-in users only, so the tool code stays about tools.

Read the details in the connector docs and the background in connector: true.

Deploy guides

FAQ

Do I need an OAuth library in my MCP server?

No. With connector set to true, DenkOps handles discovery, registration, sign-in and tokens in front of your server. Your code receives only authenticated requests.

Which sign-in providers are supported?

Google, GitHub and Microsoft, plus email and password, which is useful for marketplace reviewer accounts. You choose per connector.

Can I restrict a connector to specific people?

Yes. A connector is either public or limited to an allowed-email list you manage in the dashboard Access tab.

Does it work with claude.ai and ChatGPT?

Yes. Both discover the authorization server from the 401 challenge and register themselves, so users only see the sign-in and consent pages.