Set Up MCP Authentication
Steps
Make connecting agents authenticate as real wiki users, so that what they may read and write is bounded by that user's rights (see MCP User Permissions). This page sets up the browser sign-in flow that agents such as OpenCode use. Until it is set up, an unauthenticated caller is refused with HTTP 401 unless the wiki allows guest access, in which case the caller is served as the guest user with read tools only, and a client must be given credentials itself.
- Install the OpenID Connect Provider extension.
- Open "Users & Rights > OpenID Connect" in the wiki's administration and set the clients to "Dynamic mode".
- Open "Users & Rights > Authentication" and set the authenticator to "Token based authenticator" (see "Select the Authenticator").
- Set up a fallback authenticator if the wiki still needs its own login form (see the OpenID Connect Provider documentation).
- Connect an agent and check that it is sent through the login flow. With guest access off, the first unauthenticated call receives HTTP 401 with a WWW-Authenticate header pointing at this wiki's protected-resource metadata, and the client then opens the consent screen.
FAQ
What happens if I set up no authentication at all?
The endpoint uses whatever authentication XWiki is configured with and does not ask for any of its own. An unauthenticated caller is refused with HTTP 401 unless the wiki allows guest access, and a caller that presents credentials which fail to authenticate is always refused, even with guest access on.
Is the OIDC Provider required?
For the browser sign-in flow on this page, yes. Without it the endpoint answers a bare 401 with no WWW-Authenticate challenge, so the client cannot discover a provider; configure the client with credentials itself instead, for example HTTP Basic, which XWiki's authenticator checks like any other request.
Does guest access replace authentication?
No. With guest access on, a caller that sends no credentials at all is served as the guest user and never sees the login flow. A request that sends credentials which fail is still refused with 401.
Which user is an agent then acting as?
The one it authenticated as, with that account's rights and nothing more, which is why the account you hand to an agent matters: see MCP User Permissions.
How can I see what an agent did?
Every tool call is logged at INFO with the tool, the acting user, the outcome (ok, error, refused or failed) and the duration. The arguments are never logged.
