[feature]: Add OAuth app registration to CE for MCP server support

[wildsurfer]

Is there an existing issue for this?

• I have searched the existing issues

Summary

Add OAuth app registration (/auth/o/* endpoints) to Plane CE so that plane-mcp-server's HTTP transport with per-user OAuth works against self-hosted instances. Currently these endpoints only exist on Plane Cloud, leaving self-hosted users with no multi-user auth option for MCP.

Why should this be worked on?

Self-hosted teams have no way to use plane-mcp-server with per-user auth. The MCP server's OAuth flow is already built — it proxies through /auth/o/authorize-app/, /auth/o/token/, and /auth/o/app-installation/ — but these endpoints don't exist in CE. There's no OAuth app model in plane/db/models/, no registration UI, and no way to get a client_id/client_secret. Pointing PLANE_BASE_URL at a self-hosted instance just 404s.

This blocks non-coding use cases — project managers and team leads using MCP-compatible tools like Claude Desktop to interact with Plane, without setting up stdio or sharing a single API token. Ideally the MCP server would be another service in the default docker-compose.yml, with per-user OAuth working the same way it does on Cloud.

[makeplane]

Synced with Plane Workspace 🔄

[GIT-129] [feature]: Add OAuth app registration to CE for MCP server support

[rhinodave]

Adding a +1 from a different angle that may broaden the case for this work.

We're running self-hosted Plane (plane.thinkandactlocally.com) on a Federated Computer instance as part of the Council on Local Relations — a deliberative-roles framework we run internally with 19 seats (Engineer, Strategist, Herald, Headmaster, etc.), each of which produces decisions and work. We've built an internal automation tool — A2, a Multi-Tool Update Agent — that processes seat session summaries and writes structured updates to BookStack, Baserow, Gitea, and the local filesystem.

The fifth target was Plane. We hit exactly the auth ceiling this issue describes, just from a different direction:

GET /api/v1/workspaces/<slug>/projects/<uuid>/
Authorization: X-API-Key plane_api_...

→ HTTP 403
{"detail":"You do not have permission to perform this action."}

The PAT authenticates (else we'd see 401) but is rejected on permission grounds for project-scoped GETs, even though the token's owner-user has Admin role on the workspace and can access the project freely in the browser. Reproducing outside our adapter via plain curl gives the same response.

We did the investigation @wildsurfer's issue body covers — there's no scope UI on PAT creation, no workspace-token surface, and god-mode (which is reachable on our instance) doesn't expose token issuance beyond user-level OAuth providers. The Plane Python SDK's OAuthClient has the right shape (get_client_credentials_token, exchange_code, refresh, revoke) but those endpoints 404 against a self-hosted instance, which matches what's described here.

Our use case is "non-MCP" but lands in the same place. A2 isn't an MCP client. It's a small Python agent we wrote to keep our federated stack coherent. Without OAuth-app endpoints in CE, we have three options, all worse than we'd like: (1) embed an admin-user password in .env and screen-scrape session-cookie auth, (2) write directly to the Plane Postgres database and skip the API, or (3) accept that A2 can't write to Plane and run our work-item tracker outside the otherwise-uniform automation surface.

The four other federated-stack tools (BookStack, Baserow, Gitea, Filesystem) all have machine-friendly auth and integrate cleanly. Plane is the one we want to keep — its UI is excellent for daily Council work — but the auth model is the only thing standing between "operational" and "blocked-structurally" for our use case.

Posting this as a +1 with the additional civic-governance framing in case the use-case breadth helps prioritize. Saw the Apr 6 commit (01b8027 — OAuth app registration models for CE) so this is clearly already in motion; happy to share A2 source, run logs, or test against a CE branch once the endpoints land, if that's useful.

Thanks for the work on Plane and for shipping this as open source. Standing by.

— David Campbell, Chairman, Council on Local Relations

[Maziak2520]

Hi @vihar @pushya22 — we've hit this exact limitation on a self-hosted Community deployment: we want to use plane-mcp-server as a remote connector (Claude.ai / Claude Desktop) against our self-hosted instance, but the MCP server's OAuth flow proxies to /auth/o/authorize-app/, /auth/o/token/ and /auth/o/app-installation/, and none of those endpoints exist in CE (they 404). The REST API + Personal Access Tokens work fine, but there's no per-user OAuth path for self-hosted teams.

Since this issue is assigned to you, I wanted to coordinate before doing any work rather than open a surprise PR:

1. Would you accept a community PR that adds OAuth application registration to CE? Or is this intentionally reserved for Cloud/Commercial, in which case we'll plan around it.
2. Is there already a WIP / internal design? (A comment here referenced OAuth models being in development.) If so, we're happy to test, review, or fill specific gaps rather than duplicate effort.
3. If a PR is welcome, any constraints on design/placement — e.g. should the OAuth app + token models live under a new plane.oauth app in apps/api/, should app registration be admin-only (apps/admin) vs workspace-scoped (apps/web), and any requirements around PKCE, token storage/rotation, and rate limiting we should follow to match your conventions?

We've written up a draft technical design (models, /auth/o/ endpoints, PKCE S256, Bearer verification alongside the existing APIKeyAuthentication, and a registration UI) that we can share or open as an RFC PR if that's the preferred path. Whatever minimizes duplicate work for your team.

Happy to jump on whatever process you prefer. Thanks!

[nileshtrivedi]

but the MCP server's OAuth flow proxies to /auth/o/authorize-app/, /auth/o/token/ and /auth/o/app-installation/, and none of those endpoints exist in CE (they 404)

I too ran into this. My Plane workspace users are unable to add self-hosted Plane MCP server to their MCP clients that uses PAT instead of the Oauth flow.

[Maziak2520]

Quick status update from our side, since there's fresh activity here (@nileshtrivedi's
report today matches exactly what we hit).

Since our June 2 comment we shipped an interim solution for our own deployment — a small
OAuth bridge in front of plane-mcp-server that authenticates each user and maps them to
their own Plane PAT — so Claude.ai connectors work against self-hosted CE today. It works,
but it's infrastructure every self-hosted team would have to duplicate, which is why we'd
still love to see this land natively.

To unblock our internal roadmap we've kept refining a concrete technical design for OAuth
app support in CE (condensed below). We plan to publish it as a full design RFC document
around 2026-07-31 unless you'd prefer we hold off — and if there's internal WIP, we're
happy to test or review that instead; whatever saves your team the most time.

One question that would really help us (and anyone else considering a PR here) —
@vihar @pushya22: Plane Cloud already runs an OAuth authorization server for the
official MCP integration. Do internal models/migrations exist that a community-added CE
implementation (new Django models + migrations under apps/api/plane/db) would conflict
with? If so, a community PR may be structurally unmergeable no matter how well it's
written, and it would be good to know before anyone invests the effort.

Condensed design (full RFC to follow):

• Goal: implement the exact contract plane-mcp-server already calls, so it works
  against CE unchanged: GET /auth/o/authorize-app/, POST /auth/o/token/,
  GET /auth/o/app-installation/, plus Bearer verification on /api/v1/users/me/.
• Protocol core on django-oauth-toolkit (or Authlib if a lighter dependency is
  preferred) rather than hand-rolled OAuth — authorization-code + PKCE (S256 only),
  refresh rotation with reuse detection, revocation.
• Plane-specific parts as custom code: app registration (instance-admin scoped,
  client_secret hashed at rest and shown once), workspace-scoped app installations, an
  OAuthBearerAuthentication DRF class alongside the existing APIKeyAuthentication,
  rate limiting via the existing throttles.
• Negative-test matrix for the standard OAuth attack classes (redirect confusion,
  auth-code injection, PKCE downgrade, token audience confusion with X-Api-Key,
  consent CSRF, refresh replay).

@rhinodave — the Apr 6 commit you referenced (01b8027) appears to live in a fork rather
than on an upstream branch; if that's your group's work, we'd be glad to align on a single
design rather than run two parallel efforts.