mcp-oidc-proxy
# mcp-oidc-proxy
Local prototype for exercising [FastMCP `OIDCProxy`](https://gofastmcp.com/servers/auth/oidc-proxy) against a demo OIDC provider.
The repository packages two cooperating apps:
- **Auth server** — a [NanoIDP](https://github.com/cdelmonte-zg/nanoidp) demo OIDC provider on `http://127.0.0.1:9000`
- **MCP server** — a FastMCP HTTP server on `http://127.0.0.1:8000` with a single protected `hello_world` tool
Together they prove that an MCP client can authenticate through `OIDCProxy`, call a protected tool, and be rejected when unauthenticated.
## Prerequisites
- [uv](https://docs.astral.sh/uv/)
- Python 3.14+
## Setup
```bash
uv sync
cp .env.example .env
```
Demo client credentials are committed in `config/` with defaults matching `.env.example`. Both servers read the same environment variable names so credentials stay aligned.
## Running locally
Run each server in its own terminal from the repository root:
```bash
uv run python -m nanoidp
```
```bash
uv run launch-mcp
```
The auth server listens on `http://127.0.0.1:9000` and exposes standard OIDC discovery, JWKS, authorize, and token endpoints. NanoIDP reads committed configuration from `./config`.
**Demo-only warning:** the auth server exists solely to validate the OIDC proxy flow during local development and testing. It is not a production identity provider.
Demo credentials:
- User: `admin` / `admin`
- OAuth client: values from `.env.example` (`mcp-proxy-client` / `dev-secret`)
## Tests
```bash
uv run pytest # unit/integration tests (smoke excluded)
uv run pytest -m smoke # end-to-end smoke tests (spawns both servers)
```
Smoke tests launch real subprocesses for NanoIDP and the MCP server, complete the OAuth flow with FastMCP `HeadlessOAuth`, and verify both authenticated and unauthenticated tool calls.
TDQS
Scored across 26 tools
Every tool targets a distinct resource and action with clear descriptions that explicitly disambiguate similar pairs (e.g., decode_token vs verify_token, create_user vs create_persona_user). No two tools have overlapping purposes.
All tool names follow a consistent verb_noun pattern in snake_case, using standard verbs like get, list, create, update, delete, rotate, and save. Minor variations (list_users vs get_user) reflect conventional list-vs-fetch semantics.
At 26 tools, the server exceeds the 25-tool threshold for 'too many' defined in the rubric. While the broad scope of an OIDC proxy justifies many operations, the count is above the well-scoped range and may overwhelm an agent with options.
The tool set provides comprehensive coverage: CRUD for users and clients, token generation and verification, key management, audit logging, and config lifecycle (validate, reload, save). Minor gaps exist (e.g., no granular audit log deletion or token introspection), but they do not create dead ends.