RFC 8414 authorization-server metadata, aliased at /.well-known/openid-configuration.

forward "/.well-known/oauth-authorization-server",
        Noizu.MCP.Auth.Server.MetadataPlug, MCPConfig.as_opts()
forward "/.well-known/openid-configuration",
        Noizu.MCP.Auth.Server.MetadataPlug, MCPConfig.as_opts()

The fields clients actually gate on

This document is not decoration — Claude reads it and decides what it is willing to do:

• code_challenge_methods_supported: ["S256"] — only S256, never plain
• token_endpoint_auth_methods_supported containing "none" — together with the next flag, this is what makes Claude offer CIMD. Drop "none" and it silently falls back to dynamic registration
• client_id_metadata_document_supported: true — the other half of that pair
• registration_endpoint — present only with dcr: [enabled: true]; its absence is how a client learns not to try
• authorization_response_iss_parameter_supported: true — and the authorization endpoint really does emit iss (RFC 9207)
• resource_indicators_supported: true — RFC 8707, which is how a client knows to ask for a token bound to one mount
• jwks_uri — only in RS256 mode. Advertising it with an HMAC key would point clients at an empty key set.

The document is public, unauthenticated and cacheable, and is served with Access-Control-Allow-Origin: * because claude.ai reads it from a browser context.