[~tmortagne] Agreed that oidc-provider cannot serve a URL outside its own context path: the servlet container dispatches on the context path before the request ever reaches the WAR, and the servlet spec gives a non-ROOT webapp no way to claim /.well-known/....
The third one is exactly what we already serve (ConfigurationOIDCEndpoint is registered with the hints "", .well-known/openid-configuration and .well-known/oauth-authorization-server), i.e. http://localhost:8080/xwiki/oidc/.well-known/openid-configuration}}. So a spec-compliant MCP client discovers our provider at {{/xwiki with no proxy and no ROOT deployment; OpenCode 1.18.4 simply stops at attempt 1. That would make this a client bug rather than ours. (In fairness, the older 2025-06-18 revision only says "follow RFC 8414" without spelling out the fallback chain, so OpenCode is not violating that one.)
Second, what actually kills the client is not a 404 but the redirect loop: /.well-known/oauth-authorization-server/xwiki/oidc 302s to /xwiki/xwiki, which 302s to itself. On a clean 404 a client falls through to attempts 2 and 3 and succeeds; a self-referential 302 loop makes it give up entirely ("The response redirected too many times"). That loop comes from XWiki's own ROOT redirect, not from the container, so this part is not "nothing we can do": should we open an XWIKI issue so that a nonexistent path under /.well-known/ does not get turned into an infinite redirect (and possibly rewrite /.well-known/*//oidc to the provider-relative URL)?
Either way, we should document the deployment constraint, because the OIDC pages currently say nothing about it. Two gaps I noticed:
Nothing states what strict RFC 8414 issuer-derived discovery requires of the deployment (XWiki as the ROOT context, or a rewrite rule in the HTTP proxy).
Vincent Massol on 07/Sep/26 11:08
\[\~tmortagne\] Agreed that {{oidc\-provider}} cannot serve a URL outside its own context path: the servlet container dispatches on the context path before the request ever reaches the WAR, and the servlet spec gives a non\-ROOT webapp no way to claim {{/.well\-known/...}}.
Two things though.
First, the current MCP specification \ requires clients to try three URLs in priority order when the issuer URL has a path component(\[see "Authorization Server Metadata Discovery|[https://modelcontextprotocol.io/specification/" in revision2025\-11\-25/basic/authorization#authorization\-server\-metadata\-discovery|:https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#authorization-server-metadata-discovery]\], revision 2025\-11\-25\) requires clients to try three URLs in priority order when the issuer URL has a path component:
h1.# OAuth 2.0 AS Authorization Server Metadata with path insertion: {{[https://host/.well\-known/oauth\-authorization\-server/tenant1}|https://host/.well-known/oauth-authorization-server/tenant1}]} h1.# OpenID Connect Discovery 1.0 with path insertion: {{[https://host/.well\-known/openid\-configuration/tenant1}|https://host/.well-known/openid-configuration/tenant1}]} h1.# OpenID Connect Discovery 1.0 with path appending: {{[https://host/tenant1/.well\-known/openid\-configuration}|https://host/tenant1/.well-known/openid-configuration}]} The third one is exactly what we already serve \(:{{ConfigurationOIDCEndpoint}} is registered with the hints {{""}}, {{.well\-known/openid\-configuration}} and {{.well\-known/oauth\-authorization\-server}}\), i.e. so {{[http://localhost:8080/xwiki/oidc/.well\-known/openid\-configuration}|http://localhost:8080/xwiki/oidc/.well-known/openid-configuration}]} answers 200. So a A spec\-compliant MCP client therefore discovers our provider at {{/xwiki}} with no proxy and no ROOT deployment; OpenCode 1.18.4 simply stops at attempt 1. That would make this a client bug rather than ours. \(In fairness, the older 2025\-06\-18 revision only says "follow RFC 8414" without spelling out the fallback chain, so OpenCode is not violating that one.\)
Second, what actually kills the client is not a 404 but the redirect loop: {{/.well\-known/oauth\-authorization\-server/xwiki/oidc}} 302s to {{/xwiki/xwiki}}, which 302s to itself. On a clean 404 a client falls through to attempts 2 and 3 and succeeds;, whereas a self\-referential 302 loop makes it give up entirely \("The response redirected too many times"\). That loop comes from XWiki's own ROOT redirect, not from the servlet container, so this part is not quite "nothing we can do": should. Should we open an XWIKI issue so that a nonexistent path under {{/.well\-known/}} does is not get turned into an infinite redirect \(,and possibly rewrite {{/. so that thewell\-known/\*//oidc}} paths derived from the context path are rewritten to the provider\-relative URL\)?
Either way, we should document the deployment constraint, because the OIDC pages currently say nothing about it. Two gaps I noticed:
* The \ "Provider metadata" entry on[OpenID Connect Provider|[https://extensions.xwiki.org/xwiki/bin/view/Extension/OpenID%20Connect/OpenID%20Connect%20Provider/|https://extensions.xwiki.org/xwiki/bin/view/Extension/OpenID%20Connect/OpenID%20Connect%20Provider/]\] page's "Provider metadata" entry still documents only {{/oidc/}} and {{/oidc/.well\-known/openid\-configuration}}: the {{.well\-known/oauth\-authorization\-server}} alias added by OIDC\-303 is not documented anywhere. * Nothing states what strict RFC 8414 issuer\-derived discovery requires of the deployment \(XWiki as the ROOT context, or a rewrite rule in the HTTP proxy\).
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
