[Bug]: Clarify how “Log-in credentials, save in session” still permits External Storage access with tokens

[traeu]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• Nextcloud Server is running on 64bit capable CPU, PHP and OS.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

My Nextcloud:
Version 24.0.4
User auth over LDAP/MS-AD
Access over NGINX reverse proxy (User-->NGINX: https/letsencrypt, NGINX-->Nextcloud: http)

I added a SMB-share to my nextcloud and used the option “Log-in credentials, save in session” for credentials.
The documentation says:
"The Log-in credentials, save in session mechanism uses the Nextcloud login credentials of the user to connect to the storage. These are not stored anywhere on the server, but rather in the user session, giving increased security."
and
"Desktop and mobile clients that use tokens to authenticate can not access those shares"

This is exactly what I want, I don't want to store credentials of users permanently on my server.

But I noticed, as soon as I added the external storage, my Nextcloud Windows client started to sync the whole smb-share. I also have access to my smb-share over my Nextcloud-iOS-App. Both apps, Windows and iOS, use token authentification as far as I can tell. How is it possible that my apps can access my smb share?
Where are the credentials stored (I guess they must be stored somewhere, because otherwise the apps would have no access?)

Here someone else experienced the same problem, but no one could help
https://help.nextcloud.com/t/external-storage-credentials-save-in-session-and-desktop-sync-how-does-this-work/92602/2

Steps to reproduce

1. add external SMB storage with option “Log-in credentials, save in session”
   2a. connect iOS app with token/QR-code
   2b. access SMB share over iOS app
   3a. alternatively, connect Windows desktop app with token
   3b. access SMB share over windows app

Expected behavior

Expected behavior as described in official documentation:
"Desktop and mobile clients that use tokens to authenticate can not access those shares"

Installation method

Community Manual installation with Archive

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.1

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost",
            "CENSORED"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "24.0.4.1",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "loglevel": 2,
        "default_phone_region": "DE",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "overwritehost": "CENSORED",
        "overwrite.cli.url": "CENSORED",
        "overwriteprotocol": "https",
        "forcessl": true,
        "overwritewebroot": "\/",
        "overwritecondaddr": "^10\\.43\\.43\\.100$",
        "htaccess.RewriteBase": "\/",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_sendmailmode": "smtp",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpsecure": "tls",
        "mail_smtpauth": 1,
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "maintenance": false,
        "theme": "",
        "default_language": "de",
        "default_locale": "de_DE",
        "defaultapp": "files",
        "knowledgebaseenabled": false,
        "allow_user_to_change_display_name": false,
        "remember_login_cookie_lifetime": 2592000,
        "session_lifetime": 172800,
        "session_relaxed_expiry": true,
        "auth.webauthn.enabled": false,
        "skeletondirectory": "\/var\/www\/nextcloud\/core\/skeleton_new",
        "lost_password_link": "mailto:CENSORED",
        "trashbin_retention_obligation": "30,30",
        "ldapUserCleanupInterval": 16,
        "sort_groups_by_name": true,
        "profile.enabled": false
    }
}

List of activated Apps

Enabled:
  - activity: 2.16.0
  - admin_audit: 1.14.0
  - bruteforcesettings: 2.4.0
  - cloud_federation_api: 1.7.0
  - comments: 1.14.0
  - dav: 1.22.0
  - federatedfilesharing: 1.14.0
  - files: 1.19.0
  - files_external: 1.16.1
  - files_pdfviewer: 2.5.0
  - files_rightclick: 1.3.0
  - files_sharing: 1.16.2
  - files_trashbin: 1.14.0
  - files_videoplayer: 1.13.0
  - logreader: 2.9.0
  - lookup_server_connector: 1.12.0
  - notifications: 2.12.0
  - oauth2: 1.12.0
  - password_policy: 1.14.0
  - provisioning_api: 1.14.0
  - quota_warning: 1.14.0
  - serverinfo: 1.14.0
  - settings: 1.6.0
  - systemtags: 1.14.0
  - tasks: 0.14.4
  - text: 3.5.1
  - theming: 1.15.0
  - twofactor_backupcodes: 1.13.0
  - updatenotification: 1.14.0
  - user_ldap: 1.14.1
  - viewer: 1.8.0
  - workflowengine: 2.6.0
Disabled:
  - accessibility: 1.8.0
  - circles: 24.0.1
  - contactsinteraction: 1.5.0
  - dashboard: 7.2.0
  - encryption
  - federation: 1.12.0
  - files_versions: 1.17.0
  - firstrunwizard: 2.11.0
  - nextcloud_announcements: 1.11.0
  - photos: 1.6.0
  - privacy: 1.8.0
  - recommendations: 1.3.0
  - sharebymail: 1.14.0
  - support: 1.5.0
  - survey_client: 1.10.0
  - user_status: 1.2.0
  - weather_status: 1.2.0

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

No response

Additional info

No response

[traeu]

Problem/behavior is still the same on 25.0.3

Share is set up like this:

Windows- and iPhone-Client are connected with device password, they don't know my LDAP-login credentials.

Still I can access the SMB-shares with mit iPhone- and my WIndows-Nextcloud-client.

I still don't know why this is possible, documentation says:
"Desktop and mobile clients that use tokens to authenticate can not access those shares"

[traeu]

Today I synced this external share with nextclouds official client on macOS. The sync client is connected with device password, it does not know the LDAP credentials.
On first try, the sync did not succeed. There was an error message saying that I try to sync an external mounted storage (which is correct, that's exactly what I did) and that this is not possible.
But on second try, after un-checking the external folder and checking it again, the client started to sync the external storage.

I still wonder why this is possible and if user credentials are somewhere stored on the nextcloud server even if I use “Log-in credentials, save in session” for mounting external storage. I really don't want that my nextcloud server knows the LDAP credentials of all my users.

[traeu]

Is there any update to this?
Latest documentation https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/external_storage/auth_mechanisms.html still says

The Log-in credentials, save in session mechanism uses the Nextcloud login credentials of the user to connect to the storage. These are not stored anywhere on the server, but rather in the user session, giving increased security. This method has some important drawbacks, since Nextcloud has no access to the storage credentials and therefore cannot perform any background tasks on the storage:
(...)
Desktop and mobile clients that use tokens to authenticate can not access those shares

[joshtrichards]

I think the docs need some updating and clarity here, at a minimum. That line was added as a result of a discussion in #19561 but I'm not sure it was accurate after #2044. I'm not going to have time to look at this any time soon, but noting for the future.