Repository navigation
AS issuer validation failure #140
Description
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:
- Run
metadata-var2ormetadata-var3conformance test with a working SDK and inspectchecks.json.
Expected behavior
I would expect the issuer field to contain the path component used to construct the AS metadata URL.
Activity
pcarleton commentedon Feb 12, 2026
ah you're right! that should be adjusted
fix: include tenant path in auth server `issuer` claim
maciej-kisiel commentedon Feb 19, 2026
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.
fix: include tenant path in auth server `issuer` claim (#152)
pcarleton commentedon Feb 20, 2026
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 to0.12.1which would be easier for people to upgrade to. But since we have0.1.13as 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 commentedon Feb 20, 2026
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 commentedon Feb 27, 2026
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-backcompatscenario, 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 commentedon Mar 2, 2026
thanks for flagging @maciej-kisiel , re-opening.
we may want to add these as negative tests to ensure SDK's are validating issuers
fix: rename routePrefix to issuerPath and add issuer-mismatch scenario