Write calls to the core Provisioning API's fail

ℹ️ Support
, , , ,
1
Support intro

Sorry to hear you’re facing problems. :slightly_frowning_face:

The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.

If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.

Getting help

In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.

Before clicking submit: Please check if your query is already addressed via the following resources:

(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can. :heart:

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • 33.0.8 (33.0.8.2 per status.php)
  • Operating system and version (e.g., Ubuntu 24.04):
    • Ubuntu 24.04.4 LTS
  • Web server and version (e.g, Apache 2.4.25):
    *
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • replace me
  • PHP version (e.g, 8.3):
    • PHP 8.3.33
  • Is this the first time you’ve seen this error? (Yes / No):
    • yes
  • When did this problem seem to first start?
    • today
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • AIO
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • yes, cloudflare

Summary of the issue you are facing:

  • Relevant apps/capabilities: provisioning_api v1.23.0, tables (Tables app, API v2), groupfolders, bruteforce, password_policy all enabled
  • Auth method affected: HTTP Basic Auth using an app password (generated under Settings → Security → App passwords), for an account that is a member of the admin group

Problem
Every write call to the core Provisioning API’s Users/Groups controllers fails with:

{"status":"failure","statuscode":403,"message":"Password confirmation is required"}

This happens consistently regardless of:

  • endpoint version (/ocs/v1.php/cloud/... and /ocs/v2.php/cloud/... both fail identically)
  • payload encoding (form-urlencoded and JSON body both fail identically)
  • the specific action — reproduced on all of:
    • POST /ocs/v1.php/cloud/groups (create group, with or without displayname)
    • POST /ocs/v1.php/cloud/users/{userid}/groups (add user to group)
    • DELETE /ocs/v1.php/cloud/users/{userid}/groups (remove user from group)
    • PUT /ocs/v1.php/cloud/users/{userid} (edit own account’s displayname, even as a true no-op — same value written back)

What does work: Using the account’s real login password (instead of the app password) via the exact same Basic Auth mechanism for the exact same calls succeeds immediately (statuscode 100). This isolates the cause precisely to app-password vs. real-password authentication, not to session state, timing, or a specific endpoint.

What is unaffected: Nextcloud Tables API write calls (create table, create column, create row, create share) succeed normally with the same app password. So this is specific to the core Provisioning API’s user/group management surface, not a general “no writes via app password” policy.

Question for support

  1. Is this intentional hardening (app passwords deliberately excluded from confirming sensitive Provisioning API actions), and if so, since which version was this introduced/changed?
  2. Is there a supported, non-interactive way to perform group/user management via the Provisioning API for unattended automation (e.g., a scoped token type, a config.php setting, an admin-issued API key that is exempt from password confirmation)?
  3. If real-password Basic Auth is the only supported path for this, is there official guidance on securely automating this (e.g., a recommended credential-storage pattern), given that using the real account password in an unattended script is a materially larger security exposure than an app password?

Steps to replicate it (hint: details matter!):

  1. curl -s -u "$NC_USER" -X POST \
  -H "OCS-APIRequest: true" \
  -d "groupid=bg-bibliothek" \
  "$NC_BASE_URL/ocs/v1.php/cloud/users/<gueltige-userid>/groups?format=json"

  2. app passwort eintippen

  3. status code = 403