Is your feature request related to a problem? Please describe.

I'm frustrated when trying to test OAuth/authentication flows in development environments that use custom local hostnames (e.g., test.example.local, dev.myapp.local) instead of localhost. The current checkIssuerUrl function in server/auth/router.js only allows localhost and 127.0.0.1 as exceptions to the HTTPS requirement, but many development setups use custom .local domains or other hostname patterns for testing purposes.

This limitation forces developers to either:

1. Set up HTTPS certificates for development (complex and unnecessary overhead)
2. Modify their local development setup to use localhost (which may break other parts of their workflow)
3. Work around the validation by patching/mocking the library code

Describe the solution you'd like

I would like the ability to configure additional hostnames that should be exempt from the HTTPS requirement during development. This could be implemented in several ways:

1. Environment variable approach: Allow specifying additional development hostnames via an environment variable:

   const devHostnames = process.env.MCP_DEV_HOSTNAMES?.split(',') || [];
   const isDevHostname = issuer.hostname === "localhost" || 
                        issuer.hostname === "127.0.0.1" || 
                        devHostnames.includes(issuer.hostname);

2. Configuration option: Add a configuration parameter to allow custom development hostnames:

   const checkIssuerUrl = (issuer, options = {}) => {
     const devHostnames = options.devHostnames || [];
     const isDevHostname = issuer.hostname === "localhost" || 
                          issuer.hostname === "127.0.0.1" || 
                          devHostnames.includes(issuer.hostname);

3. Pattern matching: Allow hostname patterns (e.g., *.local, *.dev) for more flexible development setup.

Describe alternatives you've considered

1. Using localhost only: This works but requires restructuring development environments and may conflict with other tools or services.

2. Setting up local HTTPS: While technically correct, this adds significant complexity to development setup and is unnecessary for local testing.

3. Mocking/patching the function: This is what I'm currently doing with tools like rewire, but it's fragile and requires maintaining patches across library updates.

4. Reverse proxy setup: Using tools like ngrok or local reverse proxies to provide HTTPS, but this adds latency and complexity to the development workflow.

Additional context

The current code comment acknowledges that the localhost exemption is "for ease of testing" and that it's not technically compliant with RFC 8414. Extending this pragmatic approach to other development hostnames would maintain the same security posture (development-only exemption) while supporting more diverse development workflows.

Common development hostname patterns that would benefit from this:

• *.local domains (used by many development tools)
• *.dev domains
• *.test domains
• Custom internal development domains

This change would maintain backward compatibility while providing the flexibility needed for modern development workflows.