Allow registration_endpoint scheme (http[s]) to match whatever is used when accessing OAuth server metadata

[eojthebrave]

The registration_endpoint URL in provided at /.well-known/oauth-authorization-server and other /.well-known/* URLs is always set to HTTPS regardless of wether you access https://example.com/.well-known/oauth-authorization-server or http://example.com/.well-known/oauth-authorization-server.

This causes issues when trying to test various different clients locally. In my case I'm using DDEV, but this would probably be true for any locally signed certificate. Any client that uses Node.js as the backend is going to have issues accepting these certificates without passing a flag to Node. Which ... you mostly can't when running a client like Claude Code or Claude Desktop, or MCPJam, etc.

Many clients will allow the use of HTTP for testing. But, it doesn't work because the registration_endpoint scheme doesn't match and the client will reject it.

Example:

{
  "issuer": "http://dmetng.ddev.site/",
  "response_types_supported": [
    "code",
    "id_token"
  ],
  "response_modes_supported": [
    "query",
    "fragment",
    "form_post"
  ],
  "authorization_endpoint": "http://dmetng.ddev.site/oauth/authorize",
  "token_endpoint": "http://dmetng.ddev.site/oauth/token",
  "jwks_uri": "http://dmetng.ddev.site/.well-known/jwks.json",
  "userinfo_endpoint": "http://dmetng.ddev.site/oauth/userinfo",
  "registration_endpoint": "https://dmetng.ddev.site/oauth/register",
  "revocation_endpoint": "http://dmetng.ddev.site/oauth/revoke",
  "introspection_endpoint": "http://dmetng.ddev.site/oauth/introspect",
  "device_authorization_endpoint": "http://dmetng.ddev.site/oauth/device_authorization",
  "oauth_authorization_server_metadata_endpoint": "http://dmetng.ddev.site/.well-known/oauth-authorization-server",
  "grant_types_supported": [
    "authorization_code",
    "refresh_token",
    "client_credentials",
    "urn:ietf:params:oauth:grant-type:device_code",
    "native_app_authorization_code"
  ],
  "scopes_supported": [
    "view_members_only_content",
    "openid",
    "profile",
    "email",
    "phone",
    "address"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_post",
    "client_secret_basic"
  ],
  "token_endpoint_auth_signing_alg_values_supported": [
    "RS256"
  ],
  "code_challenge_methods_supported": [
    "S256",
    "plain"
  ],
  "request_uri_parameter_supported": false,
  "require_request_uri_registration": false,
  "claims_supported": [
    "sub",
    "iss",
    "aud",
    "exp",
    "iat",
    "auth_time",
    "name",
    "given_name",
    "family_name",
    "preferred_username",
    "email",
    "email_verified"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "service_documentation": "https://www.drupal.org/project/simple_oauth",
  "ui_locales_supported": [
    "en-US"
  ]
}

This is happening in \Drupal\simple_oauth_server_metadata\Service\ServerMetadataService::addConfigurableFields. When you get to that method the endpoint is initially set to http, but then whatever you have in config (which is required to be https by the config form) overrides whatever was auto-detected.

It's not clear to me why this endpoint needs to be configurable. But if for example I delete the code that overrides the existing value with the stored config value, so that the auto-detected URL is used I'm able to do things like claude mcp add drupal-mcp http://dmetng.ddev.site/_mcp --transport http --scope project and have authentication work. With that override in place clade would not be able to authenticate because the https vs http mismatch.

This is also true in MCPJam, and a few other tests I've tried.