How the XWiki and Nextcloud integration lets users reach wiki content
The XWiki and Nextcloud integration combines the xwiki-contrib Nextcloud application, the XWiki app from the Nextcloud app store and the OpenID Connect provider bridge, so people who work in Nextcloud for files and chat can log in to XWiki from Nextcloud and reach wiki content without a separate sign-in. Teams that keep documentation in XWiki but do their daily work in Nextcloud usually want exactly this: one login and a short path from a Nextcloud screen into the right wiki page. The OpenID Connect layer carries that login. XWiki provides the identity side through the OpenID Connect Provider extension, and the Nextcloud side trusts it through the bridge. The integration is about getting users into wiki content. On its own, it does not copy wiki pages into Nextcloud folders. Confirm the exact behavior in each direction with the vendor and in your own test environment before you promise it to users.
The integration is planned and built inside infrastructure you control. XWiki and Nextcloud both run on your servers, cloud accounts or data center, and the bridge operates between them on your network. The scope, including which XWiki instance, which Nextcloud instance and which hostnames are involved, is agreed in writing before work begins. The components have concrete minimums. The xwiki-contrib Nextcloud application requires the OpenID Connect Provider extension, the OIDCBridgeAuth authentication class in xwiki.cfg and XWiki 11.10 or later. The XWiki app from the Nextcloud app store supports Nextcloud 25 through 35, and version 1.0.2 was the latest stable release at the time of research. Check your XWiki version and your Nextcloud version against these minimums first, then choose the target versions on the basis of your own upgrade policy.
Nextcloud's release cadence sets the ongoing effort for this integration. Nextcloud publishes a new major version every four months and supports each one for a year through monthly maintenance releases. It does not allow skipping major releases during upgrades, so each major step must pass through every intermediate version. The XWiki app has to be rechecked against the supported range at every step. Nextcloud's guidance is to back up before every upgrade and to disable third-party apps until they are confirmed compatible, so plan a staging run of the login flow with the XWiki app enabled before each production upgrade. Ask whoever runs your Nextcloud operations to name the owner of that check, because it recurs for as long as both systems run.
Decide early how identities line up. Users need an XWiki account that the OpenID Connect bridge can authenticate, so confirm how accounts are created, how Nextcloud users are matched to XWiki users and what happens when someone leaves the organization and loses access in one system but not the other. If your directory is Active Directory or Microsoft Entra ID, or you already run Keycloak, the identity choices are covered in the sibling SSO topics, and the bridge should be tested against the same source of truth you plan to use everywhere else. Run a test plan with pilot users in a non-production copy of both systems. Cover login from Nextcloud, first login for new accounts, logout and a user removed from XWiki. Record the results so later upgrade checks have a baseline to compare against.
What you need before connecting XWiki to Nextcloud
Both platforms must be ready before either side is configured. The xwiki-contrib Nextcloud application depends on the OpenID Connect Provider extension, a change to xwiki.cfg and the XWiki app from the Nextcloud app store. Check each item below in the environment where both systems will run, and confirm versions before you request a quote or schedule the build.
XWiki version and support line
The xwiki-contrib Nextcloud application needs XWiki 11.10 or later, so any older installation must be upgraded first. XWiki publishes a stable line, a long term support (LTS) line and an intermediate LTS line, and each suits a different upgrade cadence. Confirm which line your support policy allows before choosing a version, then map the upgrade path to it. The 11.10 minimum is only a floor, so choose the target line deliberately.
Nextcloud and XWiki app versions
The XWiki app in the Nextcloud app store supports Nextcloud 25 through 35. Check that your Nextcloud server release falls in that range and is still receiving maintenance, because Nextcloud supports each major version for one year. Version 1.0.2 was the latest stable app release at the time of research, so confirm the current release in the app store before installation. Plan any Nextcloud upgrade one major version at a time.
OpenID Connect Provider extension
The bridge relies on XWiki acting as an OpenID Connect provider, which the xwiki-contrib OpenID Connect extension supplies. Install it on the XWiki side and confirm it supports the XWiki line you selected. Decide which client registration and redirect addresses Nextcloud will use, since these values must match exactly at both ends. Test sign-in with a non-administrative account before anyone relies on the integration.
OIDCBridgeAuth in xwiki.cfg
The Nextcloud application requires the OIDCBridgeAuth authentication class to be enabled in xwiki.cfg. This is a configuration change on the XWiki server, so it should pass through your change control process. Keep a copy of the original file and record the previous value so you can restore it if sign-in breaks. Confirm whether a restart is needed, and check the exact property syntax against the documentation for your XWiki version.
HTTPS and resolvable DNS names
Each platform must reach the other by a stable DNS name over HTTPS, because OpenID Connect redirects and token exchanges depend on it. Use the same names in both configurations, and confirm that both servers trust the certificates involved, including any certificates issued by an internal authority. Check firewall rules and reverse proxies in both directions, including server-to-server calls that never pass through a user's browser. Hostname mismatches often surface as failed sign-in.
Accounts and administrative access
Plan who holds administrative rights on each side before configuration begins. On XWiki you need an account that can install extensions and edit server configuration, and on Nextcloud an administrator who can install apps and manage user authentication. Create a dedicated integration account where the product supports it, record who can change each setting, and confirm that test users exist in both systems with matching identifiers.
Which component runs where in the Nextcloud and XWiki connection
Three separate pieces make up this connection, and each one has a different job. The xwiki-contrib Nextcloud application, the XWiki app from the Nextcloud app store and the OpenID Connect Provider extension on the XWiki side do not all run in the same place. Before anyone edits a configuration file, the team should write down which system issues the login, which system holds the wiki pages and attachments, and which pieces carry each job. Mixing these up is the most common reason a first attempt fails, because a login error on one side can look like a content error on the other.
The xwiki-contrib Nextcloud application lets Nextcloud users sign in to XWiki from Nextcloud. Its stated requirements point to the XWiki side of the connection: it needs the OpenID Connect Provider extension, the OIDCBridgeAuth authentication class configured in xwiki.cfg, and XWiki 11.10 or later. The team should confirm the exact installation location, the required XWiki and Nextcloud versions and any additional settings against the repository README for the release it plans to deploy. Treat the README as the source of truth for the split, not a general description of how these projects are usually installed.
The XWiki app in the Nextcloud app store is a Nextcloud-side component. Its listing states support for Nextcloud 25 through 35, and version 1.0.2 was the latest stable release at the time of research. That support range is tied to the Nextcloud server version, so the Nextcloud upgrade plan and the app version have to be checked together. The team should confirm, in the app listing and its documentation, which XWiki address and settings the app expects, and whether the Nextcloud server must be able to reach XWiki directly over the network.
The OpenID Connect Provider extension runs on the XWiki side and makes XWiki act as the identity provider for this flow. It issues the tokens that Nextcloud relies on. Knowing this determines who owns the account lifecycle, where session and token problems show up, which server must stay reachable for sign-in to work, and which upgrade must be coordinated with which. The team should also decide which XWiki instance is the authoritative source for users, record the planned XWiki and Nextcloud versions, and confirm the extension version that matches them before any configuration begins.
Configuring the XWiki and Nextcloud integration step by step
This sequence connects XWiki and Nextcloud so that Nextcloud users can sign in to XWiki and reach their wiki content from inside Nextcloud. Each step builds on the one before it, and each closes with a check you can run before moving on. Exact client settings and redirect URIs come from the repository documentation for the versions you install.
Confirm both platform versions and upgrade state
Record the XWiki and Nextcloud versions in use and confirm they meet the requirements in the xwiki-contrib Nextcloud application documentation, which requires XWiki 11.10 or later. Check that the Nextcloud app store listing supports your Nextcloud release, since the XWiki app supports Nextcloud 25 through 35. Nextcloud does not allow skipping major releases, so if either platform is behind, complete the upgrades one major version at a time, with a backup before each one, before installing any integration component. Done when you have a written version record for both platforms and a tested backup you can restore from.
Install the OpenID Connect provider extension
An XWiki administrator installs the OpenID Connect Provider extension from the xwiki-contrib oidc project on the wiki instance that will act as the identity provider for Nextcloud. Use a test instance first if one exists, and follow the install method documented for your XWiki version. The Nextcloud application depends on this extension, so the integration cannot work without it. Done when the extension appears in the installed extensions list in the administration area and the wiki loads normally after a restart.
Enable the OIDCBridgeAuth authentication class
Edit xwiki.cfg on the XWiki server to enable the OIDCBridgeAuth authentication class, which the Nextcloud application requires. Make the change in the configuration file your deployment actually reads, and keep a copy of the original file so you can roll back. Confirm the exact property name and value in the repository documentation for your installed versions before editing. Restart XWiki so the setting takes effect. Done when XWiki starts without authenticator errors in the logs and the administration pages still load.
Install the xwiki-contrib Nextcloud application
Install the xwiki-contrib Nextcloud application on the XWiki side, following the installation steps in its repository for your XWiki version. This extension is the XWiki component that connects the wiki to Nextcloud. Leave its client settings unchanged for now, because the values come from the client registration in a later step. Done when the application is listed as installed in XWiki and a wiki page still loads after the install.
Install the XWiki app in Nextcloud
A Nextcloud administrator installs the XWiki app from the Nextcloud app store. The store listing shows support for Nextcloud 25 through 35 and names version 1.0.2 as the latest stable release at the time of research, so confirm the version offered at install time against the listing. Leave the app's connection settings blank until the client registration step is complete. Done when the app appears among the enabled apps in Nextcloud and its settings page opens for an administrator.
Register the client on the provider side
Register a client for Nextcloud on the OpenID Connect provider, which is the XWiki instance from the earlier steps. Record the client identifier, the client secret and the redirect URI the registration uses, and check each value against the repository documentation for the installed versions. Store the client secret in your secrets manager and limit who can read it. Done when the client shows as registered on the provider and the redirect URI matches the documented value exactly.
Connect both applications and test sign-in
Enter the client values in the XWiki Nextcloud application and in the Nextcloud XWiki app settings, using the same identifiers and redirect URI recorded during registration. Start a sign-in from Nextcloud and confirm the browser returns to Nextcloud after authenticating in XWiki. Then open a wiki page from inside Nextcloud and check that the signed-in user matches the expected XWiki account. Done when a test login completes, the redirects land on the expected pages and the wiki page loads from inside Nextcloud.
How user identity and groups map between Nextcloud and XWiki
This table compares each identity element that crosses between Nextcloud and XWiki, from login identifier to group-based space access, and names the decision the team must make for each. Read it before configuring the OpenID Connect bridge, because a mismatch in identifiers or group names is the most common cause of duplicate accounts and wrong access. Claim and attribute names must be confirmed in your installed releases and your identity provider configuration before any mapping is built.
| Nextcloud attribute or account | XWiki user property or group | Source of truth | Decision the team must make |
|---|---|---|---|
| Login identifier (username) | XWiki user account name, derived from the identity provider subject or preferred username claim | Identity provider or Nextcloud user store, depending on the authentication backend | Pick one stable identifier, such as the subject claim, and confirm it is unchanged for the life of the account |
| Email address | XWiki user email property, used for notifications and sometimes for account matching | Identity provider mail attribute, copied into Nextcloud on first login | Decide whether email may change, and whether a changed email should update or create a separate XWiki profile |
| Display name | XWiki first name and last name fields shown on pages and in history | Identity provider given and family name claims | Decide whether users may edit names in XWiki or Nextcloud, and which system wins on conflict |
| Group membership shown in Nextcloud | XWiki group membership used for rights, if the bridge passes group claims | Identity provider group claim, confirmed against the Nextcloud user backend | Choose which groups are passed across and whether XWiki group names must match Nextcloud group names exactly |
| Group names and naming convention | XWiki group page names, which are case and character sensitive | Identity provider directory or Nextcloud group list | Agree on one naming convention and map any legacy group names before the first login |
| Wiki space access rules | XWiki space rights granted to groups, not to individual users where possible | XWiki administrators, with group membership supplied by the identity provider | Decide which spaces are open to all authenticated users, which need a named group, and who approves group membership changes |
| Administrator and rights accounts | XWiki global administrators and wiki-level rights holders | Local XWiki administrator accounts kept outside the bridge | Keep at least one local administrator path for recovery and decide who may grant admin rights through the bridge |
| Deprovisioning and disabled accounts | XWiki account state after the identity provider disables a user | Identity provider account lifecycle, with Nextcloud and XWiki sessions as dependents | Decide how quickly a disabled user loses access in each system and who checks that the state is applied |
Version compatibility and upgrade order across both platforms
Start by pinning the XWiki line and the Nextcloud line together. The XWiki app in the Nextcloud app store supports Nextcloud 25 through 35, and the XWiki-side Nextcloud application requires XWiki 11.10 or later, the OpenID Connect Provider extension and the OIDCBridgeAuth authentication class in xwiki.cfg. These are minimums that define what can work, not a target for production. At the time of research, the official XWiki Docker tags were 18.8.0 for the stable line, 17.10.14 for the long term support line and 18.4.7 for the intermediate LTS line. Choose one line, record its end of support from XWiki's published policy, and assign an owner to track that date. Then confirm the chosen XWiki version against the Nextcloud app's compatibility notes, since the app's latest stable release at research was 1.0.2.
Nextcloud does not allow skipping major releases. An instance on Nextcloud 33 must move to 34 and then to 35, one major at a time, with each step completed and checked before the next begins. Plan each major as a separate change window with a full backup taken immediately beforehand, covering both the database and the data directory, and confirm that you can restore from it. Before each upgrade, disable third-party apps, including the XWiki app, and re-enable them only after the app's compatibility with the new major is confirmed. Record the installed app list and versions before each step, because that list becomes your re-enable plan and your rollback reference. Ask each app vendor for a written compatibility statement for every major in the upgrade path.
The Nextcloud release calendar determines which line you run. Nextcloud 35 (Hub 26 Summer) was released on 16 September 2026 and reaches end of life in September 2027. Nextcloud 34 is supported until June 2027, and Nextcloud 33 until February 2027. Nextcloud 36 (Hub 27 Winter) is scheduled for 17 February 2027. For a new deployment, the newest supported line gives the longest support window, so 35 is the usual starting point if it is current when you build. An instance on 33 needs to move before its February 2027 end of support. Work backward from each end-of-life date, and leave time to test the XWiki connection on each new major before you adopt it, especially before moving onto 36 once it is released and the XWiki app lists support for it.
Decide who owns each upgrade before the calendar is set. If your own team runs both platforms, it owns the backups, the app compatibility checks, the XWiki version moves and the rollback plan for each step. Nextcloud Enterprise is sold in Standard, Premium and Ultimate tiers with a 100-user minimum. According to Nextcloud's pricing page, Standard includes one year of maintenance, while Premium adds a maintenance lifecycle of five or more years. When your planning horizon is longer than one year, that lifecycle difference can matter more than the list price comparison. Whoever you engage, ask for a written upgrade plan that lists the order of XWiki and Nextcloud steps, the backup evidence expected at each step and the test cases for the XWiki login and content links after each change.
Securing the login bridge and the data path
The Nextcloud to XWiki link combines an OpenID Connect login bridge, a Nextcloud app that sits inside Nextcloud's trust boundary and two web hosts that exchange user sessions. Each card below covers one place where that chain can fail, and what to confirm before users depend on it.
Trust between Nextcloud and the OIDC provider
Nextcloud relies on the OpenID Connect provider extension in XWiki to vouch for each user. Decide which system is the identity authority, which claims are trusted, and how a disabled XWiki account is reflected in Nextcloud sessions. Confirm the token lifetimes and what happens when the provider is unreachable, since a failed bridge should deny access rather than fall back to local accounts.
Client secrets and their storage
The bridge uses a client identifier and secret shared between the two applications. Generate a unique secret per environment, keep it out of version control and shell history, and store it in a secrets manager or protected configuration file readable only by the web server user. Plan a rotation procedure that updates both sides in one change window.
HTTPS and certificates on both hosts
Both XWiki and Nextcloud must serve login and session traffic over HTTPS with certificates that clients trust, and the redirect URIs must match the public hostnames exactly. Confirm who issues and renews certificates, how internal certificate authorities are distributed, and how expiry is monitored on each host.
Access rules between Nextcloud users and XWiki content
Signing in is only half of the control. XWiki rights decide which pages a bridged user can read or edit, and Nextcloud shows the entry point to those pages. Map which groups may open the wiki from Nextcloud, confirm that XWiki's own page rights still apply after login, and test with a non-administrative account before rollout.
Nextcloud app review and upgrade path
The XWiki app from the Nextcloud app store runs inside Nextcloud, so it is part of the trust boundary. Review its source, pin the version you approve, and confirm it supports your Nextcloud major version before upgrading. Nextcloud does not allow skipping major releases, so plan each step with a backup and disable third-party apps until they are confirmed compatible.
Logging and review of authentication events
Collect sign-in, failed login, token and logout events from both Nextcloud and XWiki in a central log store. Define who reviews them, how often, and which patterns trigger investigation, such as repeated failures for one account or sign-ins from unexpected hosts. Confirm the log retention period your policy requires before relying on these records.
How to test the integration before users depend on it
Treat the integration as unproven until a staging test plan has run against it. The plan should run on a staging copy of both Nextcloud and XWiki that matches production in the parts that affect sign-in: the XWiki Nextcloud application, the XWiki app from the Nextcloud app store, the OpenID Connect Provider extension, the OIDCBridgeAuth authentication class in xwiki.cfg, and the XWiki version family you run in production. Use test accounts and synthetic wiki content only, so a failed test cannot expose real user data or leave stray permissions behind. Confirm that the XWiki version you plan to run meets the minimum for the Nextcloud application, which requires XWiki 11.10 or later.
The first test set covers sign-in and access. Create one test account for each group that will use the integration. For each account, log in from Nextcloud into XWiki and confirm the landing page, the displayed user name and the XWiki groups the account receives. Repeat with an account that belongs to no group and with an account that should be refused. Then check the restricted space: create a space that only a named group can read, and from each test account try to open a page in it directly by URL, through XWiki search, and through any link surfaced in Nextcloud. If the restricted space appears in search results or opens by URL for an account outside the group, the test fails, even if the sign-in itself worked.
The second test set covers logout, where teams most often assume behavior they never configured. Run four cases: sign out of Nextcloud and then open XWiki in the same browser; sign out of XWiki and then open Nextcloud; end the session on one side while a second browser stays signed in on the other; and let the session expire without any sign-out. For each case, record what the user sees and whether the other side still grants access. Decide before testing which result is acceptable, for example whether signing out of Nextcloud must also end the XWiki session. That decision shapes the session and token settings you configure, so it belongs in the plan before the first run.
Repeat the full plan after every Nextcloud or XWiki upgrade, and treat each upgrade as a trigger for testing. Nextcloud publishes a new major version every four months and supports each one for a year through monthly maintenance releases. Nextcloud does not allow skipping major releases, so the staging run should follow each step of the upgrade path, and third-party apps should stay disabled until they are confirmed compatible. Check the Nextcloud versions the XWiki application declares support for before accepting a new Nextcloud major, and rerun the sign-in, restricted space and logout cases with the application versions that will ship to production.
The scope of the plan depends on the identity source and the groups in use. If Nextcloud accounts come from LDAP or Active Directory, add tests for group membership changes, disabled accounts and users who are removed from a group after their first sign-in. If the bridge depends on a separate identity provider, add tests for that provider's session timeouts and sign-out behavior. For every test, record the date, the Nextcloud and XWiki versions, the account used, the expected result, the observed result and the tester's name. Ask the owner of the application or security team to sign off the completed record before any user is onboarded, and keep it with your change log so the next upgrade can reuse it.
Common failures in the XWiki and Nextcloud login bridge
This table pairs common login failures with their likely causes and the checks you can run in configuration files, logs and version output. Work through the rows in order, because version and configuration problems produce symptoms that look like redirect or certificate faults. Most failures trace back to a version outside the supported range, a missing authentication class, or a mismatch between the two hosts.
| Symptom | Likely cause | Fix or check |
|---|---|---|
| Login from Nextcloud returns to XWiki with an error, and the bridge login option never appears | The OIDCBridgeAuth authentication class is not enabled in xwiki.cfg | Confirm that xwiki.cfg lists OIDCBridgeAuth in the authentication class setting, restart XWiki, then retry. Check the Tomcat log for class loading errors. |
| The XWiki app in Nextcloud cannot connect, or the bridge fails silently after an XWiki upgrade | XWiki is below 11.10, which is the minimum the Nextcloud application requires | Check the XWiki version in the Administration section or the image tag in use. Upgrade to a supported XWiki release before changing anything else. |
| The XWiki app is missing from the Nextcloud app list or refuses to enable | The Nextcloud version is outside 25 through 35, the range the XWiki app supports | Run the Nextcloud status command or check Settings, then Overview. Plan a one-major-version-at-a-time upgrade or a version change that stays within the supported range. |
| Identity provider returns a redirect URI mismatch or invalid client error | The redirect URI registered for the XWiki client does not match the callback address that XWiki sends, often because of a scheme, host name, port or trailing slash difference | Compare the redirect URI in the provider client settings with the callback in the XWiki log or request trace. Match scheme, host, port and path exactly, and confirm the client ID and secret in the XWiki configuration. |
| Nextcloud reports a certificate verification error or a connection refused error when it calls XWiki | Nextcloud does not trust the certificate chain presented by XWiki, the certificate name does not match the host name, or one host reaches the other over plain HTTP | From the Nextcloud host, test the XWiki address with openssl s_client and check that the chain validates and the subject matches the host name. Confirm both URLs use HTTPS and that the internal CA is in the PHP trust store used by Nextcloud. |
| A user signs in at the identity provider but lands on an XWiki error page with no profile | The user does not yet exist in XWiki, and first-login account creation did not complete | Search the XWiki log around the first login time for account creation or authentication errors. Confirm the user is not blocked in XWiki and that the claims needed for the profile, such as the user name and email, are sent by the provider. |
| Users sign in, but they see the wrong XWiki groups or lose access to spaces | The group claim name or group values sent by the provider do not match the mapping configured for XWiki groups, including case and prefix differences | Decode a sample token or inspect the user info response and compare the group claim name and values with the mapping in XWiki. Make one test account in one group, sign in, and check the resulting group membership in XWiki. |
| Nextcloud breaks after a major upgrade, and the XWiki login option or the app itself stops working | Third-party apps were not disabled before the upgrade, or the upgrade skipped a major release, so an app or the bridge is incompatible with the new version | Before any upgrade, take a backup, disable third-party apps, and upgrade one major version at a time. After the upgrade, confirm the XWiki app supports the new version in the app store, then re-enable apps one at a time and check the Nextcloud log after each. |
Questions buyers ask about the XWiki and Nextcloud integration
How much does an XWiki and Nextcloud integration cost?
The cost depends on the scope you agree in writing. The main drivers are the number of identity sources, the group rules, the number of environments, the upgrade cadence and whether you already run an OpenID Connect provider. The integration components are published as open source projects, so the software itself is not the main line item. The paid work is planning, configuration, identity provider changes, testing, staging and handover. XWiki SAS lists consulting at 1200 EUR per day, but that rate applies to customers with a Business or Enterprise support plan, according to XWiki's pricing page. Nextcloud Enterprise is a separate paid offering, with list prices starting at 71.29 euros per user per year for the Standard tier at 100 or more users, according to Nextcloud's pricing page. DeployOpen does not publish prices. A quote follows from a written scope, so ask for line items for each driver listed above.
What drives the effort of linking XWiki with Nextcloud?
Effort rises with the number of identity sources, because each one adds mapping and testing work. Group rules matter as well, since they decide which spaces and files each user can reach from Nextcloud. The number of environments, such as development, staging and production, multiplies build and test cycles. Upgrade cadence is a major factor. Nextcloud publishes a new major version every four months and supports each one for a year, and it does not allow skipping major releases, so upgrades happen in steps. Whether your team already runs an OpenID Connect provider changes the work considerably, because you may only need to add a client to an existing provider. Ask any partner to break the estimate down by these drivers so you can see which ones your team controls.
Can our internal team set up XWiki and Nextcloud integration alone?
Yes, a capable internal team can do it alone if it has the access, skills and time. The work covers Nextcloud administration, XWiki administration, the OpenID Connect bridge, the OIDCBridgeAuth authentication class in xwiki.cfg, and login and logout testing across both systems. Your team should already be comfortable with Tomcat, Nextcloud administration and OpenID Connect concepts. Many organizations use a partner for the first build, then run routine upgrades in house with a written runbook. Use that split if your team has the skills but not the capacity for a build. Before you decide, confirm that your environment meets the XWiki 11.10 or later requirement and that the Nextcloud version is in the supported range for the XWiki app.
What does an integration project need from our team?
The project needs a named technical contact who can approve scope and access decisions. Before design starts, provide admin access to both the XWiki and Nextcloud consoles, a staging copy of each system that resembles production, and identity provider administrators who can register an OpenID Connect client, configure claims and confirm group membership. Name one owner for each upgrade, with authority to schedule downtime and approve compatibility checks. Share the current versions of XWiki, Nextcloud, PHP, the database and the identity provider, along with user counts, group rules and the list of environments. Agree in advance who signs off testing and how backups will be verified before any change is made.
Do we need Nextcloud Enterprise to use the XWiki app?
The answer depends on your support requirements, not on whether the XWiki app can be installed. The XWiki app in the Nextcloud app store supports Nextcloud 25 through 35, with version 1.0.2 as the latest stable release at the time of research. Nextcloud Enterprise is a separate paid offering aimed at enterprise, public sector and education users. Its Standard tier lists prices starting at 71.29 euros per user per year at 100 or more users, according to Nextcloud's pricing page. Higher tiers add longer maintenance lifecycles, extended support hours and clustered instance support. Confirm with Nextcloud which edition and version your environment runs, and check whether the support terms you need change the upgrade plan.
Does XWiki need to act as an OpenID Connect provider?
For the xwiki-contrib Nextcloud application, yes. The application requires the OpenID Connect Provider extension, so XWiki acts as the provider for this bridge. You also need the OIDCBridgeAuth authentication class set in xwiki.cfg, and XWiki 11.10 or later. This is a specific technical requirement that is separate from your organization's main identity provider, such as Keycloak or Microsoft Entra ID. If you already run an identity provider, the design question becomes how users sign in to each system through the same identity source without duplicate accounts. Confirm the exact configuration against the current project documentation before you plan the build, because settings can change between releases.
What breaks when XWiki or Nextcloud gets upgraded?
A likely break point is a version mismatch between XWiki, the bridge extension, the XWiki app and Nextcloud itself, so check compatibility before each step. Nextcloud requires one major version at a time, a backup before every upgrade, and third-party apps disabled until they are confirmed compatible. XWiki publishes stable, LTS and intermediate LTS lines, and each line has its own release timing, so record which line you run. Token settings, claim mappings and group rules can also change behavior after an upgrade. Test login, logout, group-based access and content retrieval in staging after each step, and keep a documented rollback plan with a tested backup before you start.
Which parts of this integration are open source?
The xwiki-contrib Nextcloud application, the xwiki-contrib OpenID Connect extension and XWiki Standard are open source, and Nextcloud Server is licensed under AGPL-3.0. Open source licensing does not remove the work of planning, configuring, testing and maintaining the integration. XWiki SAS lists consulting at 1200 EUR per day for customers with a Business or Enterprise support plan. Nextcloud Enterprise is a separate paid product with its own tiers and support terms. DeployOpen plans, implements, tests, documents and supports self-hosted open source platforms inside your own infrastructure. DeployOpen does not publish prices, and a quote follows from a written scope that lists each deliverable and timeline before work starts.
How DeployOpen scopes, delivers and supports the XWiki and Nextcloud integration
DeployOpen plans, builds and hands over the link between XWiki and Nextcloud inside infrastructure you control, with both platforms and their sign-in setup scoped together. Work is agreed in a fixed-scope written document before the build starts, and ongoing support is available as a retainer. The four stages below show what each one covers.
How we scope
- The written scope names the XWiki line, LTS or stable, and the Nextcloud major release involved.
- It confirms which users sign in through Nextcloud and where XWiki accounts come from.
- Engagements are fixed-scope, and ongoing support for the link is available as a retainer after handover.
How we build
- Install the OpenID Connect Provider extension in XWiki and set the OIDCBridgeAuth authentication class in xwiki.cfg.
- Check the XWiki app in the Nextcloud app store against the agreed Nextcloud release, which supports 25 through 35.
- Confirm the xwiki-contrib application-nextcloud release matches the XWiki version, which must be 11.10 or later.
How we hand over
- Deliver a runbook covering the bridge settings, the OIDC client configuration and the test cases used during acceptance.
- Document the login path from Nextcloud into XWiki, including denied access and expired sessions.
- Record the upgrade order for both platforms, noting that Nextcloud allows one major version per step after a backup.
How we support
- Cover XWiki and Nextcloud maintenance releases and review the link after each Nextcloud monthly maintenance update.
- Check third-party Nextcloud apps for compatibility before upgrades, as the upgrade guidance calls for disabling them until confirmed.
- Agree which XWiki and Nextcloud release lines you track, and whether the retainer covers both platforms.
