Webdav access bypassing OpenID Connect user backend

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):
    • 31.0.9
  • Operating system and version (e.g., Ubuntu 24.04):
    • Debian 13
  • Web server and version (e.g, Apache 2.4.25):
    • Apache 2.4.65
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • None
  • PHP version (e.g, 8.3):
    • 8.4.11
  • Is this the first time you’ve seen this error? (Yes / No):
    • Yes
  • When did this problem seem to first start?
    • Dicovered yesterday
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • Bare Metal
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • No

Summary of the issue you are facing:

Accessing Nextcloud via webdav bypasses the oidc configuration.

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

Myabe we are doing something wrong but here is our problem.

This is our scenario:

  • Nextcloud with LDAP integration
  • Keycloak with LDAP user federation
  • OpenID Connect user backend installed and configured, mandatory, in Nextcloud
  • A LDAP federated user with 2FA configured in Keycloak
  • Running rclone via webdav to sync files to a number of different computers using the above mentioned user

Problem:

Rclone can access the files using only username and password, bypassing the configured OpenID Connect user backend. When the user logs in with a web broswer it works as expected (redirected to the Keycloak login page).

Expected:

Access should not be possible using only username and password.

Configuration

Nextcloud

The output of occ config:list system or similar is best, but, if not possible, the contents of your config.php file from /path/to/nextcloud is fine (make sure to remove any identifiable information!):

{
    system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "xxxx:xxxx:xxxx:xxxx::xxxx",
            "xxx.xxx.xxx.xxx",
            "nextcloud.erxample.com"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbtype": "mysql",
        "default_phone_region": "SE",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "ldapIgnoreNamingRules": false,
        "ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory",
        "user_oidc": {
            "allow_multiple_user_backends": true,
            "auto_provision": false,
            "disable_account_creation": true
        },
        "log_type": "file",
        "logfile": "\/var\/log\/nextcloud\/nextcloud.log",
        "logfilemode": 416,
        "loglevel": 2,
        "logdateformat": "F d, Y H:i:s",
        "lost_password_link": "disabled",
        "maintenance": false,
        "memcache.local": "\\OC\\Memcache\\APCu",
        "mysql.utf8mb4": true,
        "overwrite.cli.url": "https:\/\/nextcloud.example.com",
        "session_lifetime": 7200,
        "theme": "",
        "version": "31.0.9.1",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "twofactor_enforced": "true",
        "twofactor_enforced_groups": [
            "2FA"
        ],
        "twofactor_enforced_excluded_groups": [],
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_sendmailmode": "smtp",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "maintenance_window_start": 1,
        "simpleSignUpLink.shown": false,
        "app_install_overwrite": [],
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": "0",
            "dbindex": 0
        },
        "memcache.locking": "\\OC\\Memcache\\Redis"
    }
}

Apps

The output of occ app:list (if possible).

Enabled:
  - activity: 4.0.0
  - app_api: 5.0.2
  - bruteforcesettings: 4.0.0
  - calendar: 5.5.7
  - circles: 31.0.0
  - cloud_federation_api: 1.14.0
  - comments: 1.21.0
  - contacts: 7.3.4
  - contactsinteraction: 1.12.0
  - dashboard: 7.11.0
  - dav: 1.33.0
  - federatedfilesharing: 1.21.0
  - federation: 1.21.0
  - files: 2.3.1
  - files_downloadlimit: 4.0.0
  - files_pdfviewer: 4.0.0
  - files_reminders: 1.4.0
  - files_sharing: 1.23.1
  - files_trashbin: 1.21.0
  - files_versions: 1.24.0
  - firstrunwizard: 4.0.0
  - groupfolders: 19.1.8
  - logreader: 4.0.0
  - lookup_server_connector: 1.19.0
  - mail: 5.5.11
  - nextcloud_announcements: 3.0.0
  - notifications: 4.0.0
  - notify_push: 1.2.0
  - oauth2: 1.19.1
  - password_policy: 3.0.0
  - photos: 4.0.0
  - privacy: 3.0.0
  - profile: 1.0.0
  - provisioning_api: 1.21.0
  - recommendations: 4.0.0
  - related_resources: 2.0.0
  - richdocuments: 8.7.6
  - richdocumentscode: 25.4.504
  - serverinfo: 3.0.0
  - settings: 1.14.0
  - sharebymail: 1.21.0
  - spreed: 21.1.5
  - support: 3.0.0
  - survey_client: 3.0.0
  - systemtags: 1.21.1
  - text: 5.0.0
  - theming: 2.6.1
  - twofactor_backupcodes: 1.20.0
  - twofactor_totp: 13.0.0-dev.0
  - updatenotification: 1.21.0
  - user_ldap: 1.22.0
  - user_oidc: 8.1.0
  - user_status: 1.11.0
  - viewer: 4.0.0
  - weather_status: 1.11.0
  - webhook_listeners: 1.2.0
  - workflowengine: 2.13.0
Disabled:
  - admin_audit: 1.21.0
  - encryption: 2.19.0
  - files_external: 1.23.0
  - suspicious_login: 9.0.1
  - twofactor_nextcloud_notification: 5.0.0

Any pointers?

maybe I’m wrong but my educated guess is WebDAV doesn’t support OIDC.

I would recommend

  • you set user password to a random value
  • enforce MFA, so login with user password becomes impossible
  • the user creates app password and uses this app password for WebDAV

Yes, that’s a workaround but not a solution to the core problem and it involves setting up “local” 2FA for every user in the system.

I am using GitHub - pulsejet/nextcloud-oidc-login: Nextcloud login via a single OpenID Connect 1.0 provider and everything works correctly.

I’m not using OIDC or any other external authentication/identity provider myself.

But isn’t it the case that if you use OIDC — and it only affects the Web UI login — it actually shouldn’t change anything regarding the WebDAV endpoint? In other words, WebDAV access should still work the same way as it does when you use local authenfictaion with 2FA for web login: you need to use app passwords for direct WebDAV access.

Put differently, the Web UI and WebDAV are two separate endpoints. The first supports 2FA and/or external SSO solutions, while the latter does not. Therefore, nothing really changes regarding WebDAV access — unless you’ve used the same username/password combination without 2FA for everything before, which, even without external SSO, isn’t really a good idea in my opinion.

So my theory is that point 2 in @wwe’s bullet list might not actually be necessary — you’d just log in via SSO and then generate app passwords for apps that need to use the WebDAV endpoint, just like you would if you were only using local authentication with 2FA enabled.

Therefore, I’d say, there is no need to keep the web UI exposed for that purpose, which means that users wouldn’t be able to log in to Nextcloud with their username and password, since authentication to the webUI still redirects through Keycloak. Besides, as far as I know, app passwords cannot be used to log in to the web UI anyways, although I have not tested this.

Thank You, good to know! I also have some colleagues using Keycloak/SAML authentication that do not have this problem. This all points to a problem in the OpenID Connect user backend (or possibly a configuration error). Have filed a bug report.

no you don’t need to setup 2FA in every system.

The point is WebDAV protocol is unable to perform OIDC login flow and requires single factor user/password - an app password is nothing else - one-factor password which complicated enough so brute-force is impossible.

maybe I’m wrong but I remember according to docs app passwords are only available if you enable MFA.. maybe they also appear without MFA if you login with SSO.. the other point indeed is to make “local” login with password impossible and force the user to utilize IdP for Web login (ok this is the case already if the user doesn’t know the local random password).

As far as I know, you can always create app passwords, even if you’re only using the standard username/password login without 2FA. However, in that case, it’s not required or enforced, meaning you can still use your regular login password for things like the WebDAV endpoint.

Yeah, that’s what I was assuming, or rather, that would be my question: when using OIDC, isn’t it basically like enforcing 2FA, i.e. you can’t log in to other endpoints with your standard password anymore? If you still can, that would be kind of… well, suboptimal. :wink: But yeah, in that case, your workaround would probably be the only solution.

yes you are right.

no. by default it’s just another login method and by default it is only another button “login with ..”. There are also options to make OIDC default but a direct login URL for internal login remains accessible (I can say for sure if you can completely disable it) - in my eyes “breaking” internal login by MFA enforcement without any MFA method configured for the user is the easiest and maybe most reliable way to ensure only SSO login is allowed (and random password is just a :cherries: on the cake)

1 Like