AS issuer validation failure

[maciej-kisiel]

Describe the bug
I'm currently working on implementing client-side OAuth in Go SDK and I'm running into a conformance test failure which I'm not sure is warranted, so I would like to consult.

The issue is related to Authorization Server Metadata handling. In metadata-var2 and metadata-var3 tests, the authorization server's issuer identifier contains a non-empty path component /tenant1. According to RFC 8141 section 3.3 a client must validate if the issuer value returned by the authorization server is the same as the identifier used to create the URL for the metadata. However, the AS returns a value with no path component, for example:

 {
    "id": "outgoing-auth-response",
    "name": "Outgoing-auth-response",
    "description": "Sent 200 response for GET /.well-known/oauth-authorization-server/tenant1",
    "status": "INFO",
    "timestamp": "2026-02-10T14:02:08.022Z",
    "details": {
      "method": "GET",
      "path": "/.well-known/oauth-authorization-server/tenant1",
      "statusCode": 200,
      "headers": {
        "x-powered-by": "Express",
        "content-type": "application/json; charset=utf-8",
        "content-length": "417",
        "etag": "W/\"1a1-vdDFr5xugGjES09D01A3xMuA7xw\""
      },
      "body": {
        "issuer": "http://localhost:35909",  <--- HERE
        "authorization_endpoint": "http://localhost:35909/tenant1/authorize",
        "token_endpoint": "http://localhost:35909/tenant1/token",
        "registration_endpoint": "http://localhost:35909/tenant1/register",
        "response_types_supported": [
          "code"
        ],
        "grant_types_supported": [
          "authorization_code",
          "refresh_token"
        ],
        "code_challenge_methods_supported": [
          "S256"
        ],
        "token_endpoint_auth_methods_supported": [
          "none"
        ]
      }
    }
  },

Should this behavior be adjusted?

To Reproduce
Steps to reproduce the behavior:

1. Run metadata-var2 or metadata-var3 conformance test with a working SDK and inspect checks.json.

Expected behavior
I would expect the issuer field to contain the path component used to construct the AS metadata URL.

[pcarleton]

ah you're right! that should be adjusted

[maciej-kisiel]

It would be ideal to merge the fix before tiering kicks in. I wonder how to release it though, since you have been using patch versions for your releases.

[pcarleton]

Merging now, and will make a release!

re: patch, I think what you're saying is if we had said "tiering tests are at 0.12.x, then we could make a patch with this fix to 0.12.1 which would be easier for people to upgrade to. But since we have 0.1.13 as the tiering release, and we've made subsequent patch changes, it's less clear?

I'll do a patch release for this anyway, and the test behavior won't change for tiering.

No new tests have been added to the suite for tiering, things have just been reorganized and tagged, so using the latest release should still be fine.

We're still working out the kinks on how to evolve the test suite without creating churn when introducing new tests that aren't required yet, so feedback welcome for that.

[maciej-kisiel]

Thanks @pcarleton! I also created #162 to bump the default Node.js version in the action, since 20 no longer works with the conformance suite at HEAD.

[maciej-kisiel]

I think this is still not 100% fixed, actually the submitted fix is now causing unnecessary path addition in one case.

In the auth/2025-03-26-oauth-metadata-backcompat scenario, it is validated that the client will fetch the AS metadata from the MCP server URL root. However, the returned Issuer has a path component:

 {
    "id": "outgoing-response",
    "name": "Outgoing-response",
    "description": "Sent 200 response for GET /.well-known/oauth-authorization-server",  <--- PATH NOT USED HERE
    "status": "INFO",
    "timestamp": "2026-02-27T18:42:09.199Z",
    "details": {
      "method": "GET",
      "path": "/.well-known/oauth-authorization-server",
      "statusCode": 200,
      "headers": {
        "x-powered-by": "Express",
        "content-type": "application/json; charset=utf-8",
        "content-length": "417",
        "etag": "W/\"1a1-wtm35AnMDHNdeRBoWYrBIHiakmE\""
      },
      "body": {
        "issuer": "http://localhost:33295/oauth", <--- PATH ADDED HERE
        "authorization_endpoint": "http://localhost:33295/oauth/authorize",
        "token_endpoint": "http://localhost:33295/oauth/token",
        "registration_endpoint": "http://localhost:33295/oauth/register",
        "response_types_supported": [
          "code"
        ],
        "grant_types_supported": [
          "authorization_code",
          "refresh_token"
        ],
        "code_challenge_methods_supported": [
          "S256"
        ],
        "token_endpoint_auth_methods_supported": [
          "none"
        ]
      }
    }
  },

[pcarleton]

thanks for flagging @maciej-kisiel , re-opening.

we may want to add these as negative tests to ensure SDK's are validating issuers