OAuth authorization-server metadata is unreachable at the RFC 8414 issuer-derived path when XWiki runs under a context path

An OAuth 2.0 client that discovers the authorization server the way RFC 8414 prescribes cannot reach XWiki's metadata when XWiki is deployed under a context path (/xwiki), which is the default for the standard WAR.

What happens

For the issuer http://localhost:8080/xwiki/oidc, RFC 8414 section 3.1 puts the metadata at the host root with the issuer's path components appended:

http://localhost:8080/.well-known/oauth-authorization-server/xwiki/oidc

That URL is answered by the servlet container's ROOT context, which 302-redirects it to http://localhost:8080/xwiki/xwiki, which in turn 302-redirects to itself. A client following redirects gives up. The same happens for /.well-known/openid-configuration/xwiki/oidc.

Only the provider-relative form answers 200:

http://localhost:8080/xwiki/oidc/.well-known/oauth-authorization-server

which is what OIDC-303 added. That form is what an OpenID Connect Discovery client built from a base URL finds, but it is not the path RFC 8414 defines for an issuer that has a path component.

Why it matters

MCP (Model Context Protocol) clients do exactly this discovery. With the LLM Application's MCP server, the chain is correct up to this point:

• .../aiLLM/mcp/.well-known/oauth-protected-resource returns 200 with authorization_servers: ["http://localhost:8080/xwiki/oidc"] (RFC 9728), and the unauthenticated endpoint returns 401 with WWW-Authenticate: Bearer realm="XWiki MCP", resource_metadata=....
• The client then resolves that issuer per RFC 8414 and hits the redirect loop.

opencode mcp auth xwiki (OpenCode 1.18.4) fails with "The response redirected too many times", before a browser is ever opened.

Reproduction

With XWiki 18.6.0 and oidc-provider 2.25.4 on http://localhost:8080/xwiki:

curl -i http://localhost:8080/xwiki/oidc/.well-known/oauth-authorization-server
# 200

curl -i http://localhost:8080/.well-known/oauth-authorization-server/xwiki/oidc
# 302 -> /xwiki/xwiki, then 302 -> itself

Confirmation that this is the whole bug

Putting a reverse proxy in front that answers only /.well-known/oauth-authorization-server/xwiki/oidc from the provider-relative URL, and forwards everything else unchanged, makes the whole flow complete: dynamic client registration, the consent screen, the token, and a connected MCP server. Nothing else had to change, so the unreachable path is the only defect.

Notes

Dynamic client registration itself works (OIDC-21, OIDC-154): with the provider in Dynamic mode, registration_endpoint is advertised and POST /xwiki/oidc/register returns 201.

A deployment where XWiki is the ROOT context (issuer http://host/oidc) does not hit this, since there is no context path to collide with.