Making OAuth Work for Roboflow MCP (Remote Server)

2026-05-19-mcp-oauth-plan.md

Making OAuth Work for Roboflow MCP (Remote Server)

Context

Our MCP server (roboflow-mcp) is a remote HTTP server at mcp.roboflow.com/mcp. MCP clients (Claude Desktop, Cursor, etc.) connect to it over the network. Currently it authenticates via x-api-key header.

We want MCP clients to authenticate users via OAuth instead — the standard flow defined by the MCP spec for remote servers.

Nick has 4 open PRs (#11839, #11343, #11363, #11364) implementing "Sign in with Roboflow" — a full OAuth 2.1 provider. Mike looked at this work and concluded it doesn't help because it targets local MCP servers. This is partially correct but misses the bigger picture.

The Three Pieces Needed

Making OAuth work for a remote MCP server requires three things:

1. OAuth Provider (the hard part)

Roboflow needs to be an OAuth 2.1 authorization server — endpoints where users authenticate and authorize access:

• GET /oauth/authorize — user logs in, sees consent screen, approves scopes
• POST /oauth/token — exchanges auth code for access/refresh tokens
• POST /oauth/revoke — revokes tokens
• GET /.well-known/openid-configuration — discovery metadata

This is what Nick built in PRs #11839 and #11343. It's a standard OAuth2 provider — not tied to local or remote MCP in any way. Any OAuth client (web app, mobile app, CLI, MCP server) can use it.

2. Remote MCP Server Accepts OAuth Tokens

roboflow-mcp needs to:

• Advertise that it requires OAuth authentication (per the MCP auth spec)
• Accept Authorization: Bearer rfoa_... tokens on incoming requests
• Validate tokens against the Roboflow OAuth provider (introspection or direct verification)
• Use the token to make Roboflow API calls on behalf of the user

This is what we need to build. Nick's work doesn't cover this — his MCP client (#11363) is a local stdio server that manages its own auth flow.

3. MCP Client Handles the Browser Flow

When an MCP client (Claude Desktop, Cursor) connects to our remote server and gets told "authenticate via OAuth," the client opens the browser, handles the redirect, obtains the token, and sends it to the server.

We don't build this. The MCP clients already implement this per the MCP spec. We just need to serve the right metadata so they know where to send the user.

How Nick's Work Helps (and What It Doesn't)

PR	What it does	Useful for remote MCP?
#11839 — Permissions refactor	Restructures RBAC permissions, adds scope-to-action mapping	Yes — we need the scope/RBAC infrastructure for token validation
#11343 — OAuth provider	Full OAuth2 server on app.roboflow.com	Yes — this IS the provider our MCP server will delegate auth to
#11363 — New MCP client	Local stdio MCP server with its own OAuth flow	No — solves a different problem (local server doing client-side auth)
#11364 — Integrator docs	"Sign in with Roboflow" guide	Partially — useful as reference for understanding the provider API

Bottom line: PRs #11839 and #11343 give us the OAuth provider, which is the hardest and most critical piece. Without them we'd have to build the entire auth server from scratch. PR #11363 is irrelevant for our use case.

What We Need to Change in roboflow-mcp

A. Register as an OAuth Client

Register roboflow-mcp as an OAuth app in Roboflow (via the admin UI or API that #11343 provides). This gives us a client_id and optionally a client_secret. Configure the allowed redirect URIs and scopes.

B. Serve MCP OAuth Metadata

The MCP spec defines how a remote server advertises its auth requirements. When a client connects and isn't authenticated, the server responds with metadata pointing to:

• The authorization endpoint (app.roboflow.com/oauth/authorize)
• The token endpoint (app.roboflow.com/oauth/token)
• The client_id for this MCP server
• Required scopes

FastMCP (our framework) may already support this — check the latest FastMCP docs for OAuth/auth provider configuration.

C. Accept Bearer Tokens Instead of API Keys

Replace (or supplement) the x-api-key header check with Authorization: Bearer token validation. The rfoa_ prefixed tokens can be validated by:

• Calling the introspection endpoint (POST /oauth/introspect) on the Roboflow provider, or
• Passing them directly as api_key to Roboflow API calls (Nick's implementation makes OAuth tokens work in the existing validateToken.js path)

D. Handle Token Lifecycle

• Respond with proper 401 when tokens are expired/invalid so clients know to refresh
• Consider whether the MCP server needs to do token refresh itself or if the MCP client handles it

Suggested Approach

1. Wait for / help land #11839 and #11343 — these are prerequisites
2. Check FastMCP's OAuth support — FastMCP v3 may have built-in support for OAuth-protected remote servers, which would minimize our work
3. Register roboflow-mcp as an OAuth client in the provider
4. Update roboflow-mcp auth — swap x-api-key for Bearer token validation
5. Test with Claude Desktop / Cursor — they should handle the browser redirect automatically once the server serves correct metadata

The bulk of the protocol complexity (PKCE, consent, token exchange) lives in the provider (#11343) and the MCP clients. Our server changes should be relatively small.