---
title: "Oauth Authorization Server"
method: GET
path: "/.well-known/oauth-authorization-server/mcp"
---

# Oauth Authorization Server

`GET /.well-known/oauth-authorization-server/mcp`

## Request

- Base URL: `https://mcp.physea.ai` (the document declares no server; this is the origin it was published from)
- URL: `https://mcp.physea.ai/.well-known/oauth-authorization-server/mcp`
- Auth: none declared

Redirect authorization-server-metadata probes to the real AS (AuthKit).

Correct MCP clients read `authorization_servers` from the protected-resource
metadata (above) and fetch AS metadata FROM the AS. But several deployed clients
— and the MCP 2025-03-26 auth flow, which assumes the MCP server is its own
authorization server — instead probe RFC 8414 metadata on the RESOURCE origin.
Without a handler here they 404 and dead-end at the /mcp 401. Observed live
2026-07-02: external clients (and Jay's own connector test) hit all four AS/OIDC
well-known paths on this origin, every one 404, then bounced back to 401 — the
"MCP not working for users" report. A 302 to AuthKit's own well-known keeps the
returned metadata `issuer` matching the final fetch origin (RFC 8414 §3.3), so
strict clients accept it and inbound token validation is unchanged. The X-API-Key
path is untouched. 404 when OAuth is disabled (there is no AS to point at).

## Response `200`

Successful Response

- unknown

---

[API](https://skmtc.dev/physea/apis/liminality-router-service.md) · [All operations](https://skmtc.dev/physea/apis/liminality-router-service/llms.txt) · [OpenAPI document](https://skmtc.dev/physea/apis/liminality-router-service/revisions/5f60ddd97544?raw)