Summary

Add OAuth 2.0 support so that the Backlog MCP Server can operate as a remote MCP server, following the MCP specification's Third-Party Authorization Flow.

This addresses the long-term suggestion raised in #24 — migrating from a single shared API key to per-user OAuth 2.0 authentication.

Motivation

Currently, when running in HTTP mode, a single Backlog API key must be shared via environment variables. This makes it difficult for teams to use the MCP server safely — all requests run under one account with no per-user audit trail.

With OAuth 2.0 support, each user authenticates with their own Backlog account through the standard OAuth consent flow. This enables scenarios such as:

• An organization exposing this as a shared remote MCP server for their team
• Each team member operating under their own Backlog permissions
• No API keys shared or embedded in client-side configuration

Scope

• RFC 8414 OAuth Authorization Server Metadata
• RFC 9728 OAuth Protected Resource Metadata
• RFC 7591 Dynamic Client Registration
• Authorization Code Grant with PKCE (S256)
• Token endpoint with refresh token support
• Bearer token authentication for the MCP endpoint
• Backward compatible — stdio and local HTTP (without OAuth) continue to work unchanged

Known limitations

• OAuth mode currently supports a single Backlog organization only
• Client registrations and tokens are stored in memory and will be lost on server restart