e0ipso / e0ipso/simple_oauth_21

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

Open
#19 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
PHP
Stars
4
Forks
3
PR merge metrics
No merged PRs in 30d

Description

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:

```json
{
"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.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.