[BUG] OAuth Debugger ignoring custom Okta authorization server

[fporcaro]

Issue

An Okta instance provides a default OAuth authorization server .okta.com/oauth2/default, but it is common to create custom authorization servers so you can limit the scopes that can be used when requesting tokens and those have a custom issuer .okta.com/oauth2/<auth_server_id>.

When returning the oauth-protected-resource payload, we are returning the url of a custom authorization server. When MCP Jam hits the .well-known/oauth-authorization-server to get the details, it always uses the default auth server for the base domain, which is the default authorization server for the tenant, which doesn't have the same/correct audience, scopes or keys as the custom auth server.

Expected Behavior

If a custom issuer is returned, that should be the base url for the .well-known/oauth-authorization-server call. For example, if the oauth-protected-resource returns a payload like this:

{
  "Resource":"https://awesome-mcp-server.example.com/mcp",
  "Authorization Servers":[
    "https://my-okta-tenant.okta.com/oauth2/xyz123"
  ]
}

Then the oauth-authorization-server well-known endpoint details should be fetched using the following url:
https://my-okta-tenant.okta.com/oauth2/xyz123/.well-known/oauth-authorization-server

Platform

• npx on Windows

I do have an MCP server displaying this issue if you reach out for details, I can provide them.

[dosubot]

Hi @fporcaro! I'm Dosu and I’m helping the inspector team.

You’re right—currently, the OAuth Debugger does not construct the .well-known endpoint using the custom Okta issuer as the base. Instead, it builds discovery URLs by taking the full authorization server URL (including custom path segments like /oauth2/xyz123) and appending/inserting the .well-known path, but it never tries the direct pattern you expect: ${issuer}/.well-known/oauth-authorization-server. This means for Okta custom authorization servers, the debugger never actually hits the correct metadata endpoint, which leads to the mismatched audience, scopes, or keys you’re seeing. The relevant logic is in the buildAuthServerMetadataUrls function in the state machine implementation, which always reuses the base domain and path-inserts the well-known suffix, rather than using the issuer as the base for the well-known call as Okta requires (see code reference).

To fix this, the code should be updated so that when a custom issuer is returned (like https://my-okta-tenant.okta.com/oauth2/xyz123), the debugger fetches metadata from https://my-okta-tenant.okta.com/oauth2/xyz123/.well-known/oauth-authorization-server. As a workaround, you could manually fetch the metadata from the correct endpoint and supply it if the debugger allows, but a code change is needed for full support.

If you want implementation details or code pointers for making this change, let me know!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[chelojimenez]

Thanks for bringing this up @fporcaro

I dug into this and wanted to share what I found regarding spec compliance.

Current Behavior

Our implementation follows the MCP spec’s authorization server metadata discovery sequence for issuer URLs with path components:

1. OAuth 2.0 path-insertion: /.well-known/oauth-authorization-server/tenant1
2. OIDC path-insertion: /.well-known/openid-configuration/tenant1
3. OIDC path-appending: /tenant1/.well-known/openid-configuration

The Gap

Okta custom authorization servers expose their OAuth metadata at an OAuth path-appending location:

https://<instance>.okta.com/oauth2/<auth_server_id>/.well-known/oauth-authorization-server

This pattern isn’t required by the spec. Interestingly, the spec includes OIDC path-appending but not OAuth path-appending, even though both patterns exist in the wild.

Questions

Have you tried this with other MCP clients (e.g., Claude Desktop, Cursor, the official SDK)? How do they behave with your Okta setup?

[fporcaro]

Awesome, thanks for the quick investigation and response! I will try supplying the openid-configuration version url in the protected resource return and see if that works and I will report back here.
We have tried other clients and had similar results with not as good of feedback, so I figured I would work through the flow here, then once I have it working with MCP Jam, try the others.

Thanks for building such a helpful tool, I would not have made it this far without your work.

[matteo8p]

Hey @fporcaro do you have any updates on what you found, if any? I'm trying to understand what the issue is. My understanding is that you want the correct Authorization Servers URL returned that includes the custom issuer / auth_server_id.

Our OAuth debugger is spec compliant. According to the spec, clients take the first URL in authorization_servers and append /.well-known/oauth-authorization-server to it.

It sounds like the fix is required on your MCP server's end. To handle returning the URL with the customer issuer, you'll have to include the full URL Resource Metadata response body:

{
  "Resource":"https://awesome-mcp-server.example.com/mcp",
  "Authorization Servers":[
    "https://my-okta-tenant.okta.com/oauth2/xyz123"
  ]
}

Our goal is to stay spec compliant, we shouldn't be modifying our client to handle a specific Okta case. I hope you're able to resolve the issue, and update me on what you find! Please feel free to reach out any time, happy to help.

[matteo8p]

Closing this issue out