[Bug]: App password gets invalidated by PublicKeyTokenProvider after 5 minutes

[samuel-larsson]

⚠️ 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 OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

App-passwords (auth tokens) created through:

sudo -u www-data php occ user:auth-tokens:add <user>

are invalidated 5 minutes (with a few seconds difference every time) after creation. During the first 5 minutes they work perfectly for WebDAV and OCS API calls.

After ~300 seconds the next request fails with response status code 503 and:

Session token credentials are invalid
OC\Authentication\Exceptions\TokenPasswordExpiredException

and in the database the token’s password_invalid field flips from 0 → 1.

This happens both for normal local users and SAML users.

I have tried to disable external IdP, password-policy, and all background-jobs, but no I have had no difference.

Steps to reproduce

1. Create a new permanent token using the user password when prompted for a password:
   sudo -u www-data php occ user:auth-tokens:add <username>
2. Output: App password: <app-password>
3. Test the password immediately: curl -u <username>:<token> https://nextcloud-poc.dc.kau.se/remote.php/dav/files/<username>/ -I
   → Response status 200
4. Wait 5+ minutes.
5. Repeat the same request.
   → Response status 503 Service unavailable, and then 401 Unauthorized on the next one.
6. Check database:
   SELECT id,name,type,last_activity,password_invalid FROM oc_authtoken ORDER BY id DESC LIMIT 3;
   The token row now has password_invalid = 1.

Expected behavior

Permanent app tokens (type 1) should remain valid indefinitely unless explicitly revoked or the user password changes. They should not expire after 5 minutes nor set password_invalid = 1.

Actual behavior:
App tokens created via occ user:auth-tokens:add are invalidated after 5 minutes of inactivity, throwing TokenPasswordExpiredException on next use after 5 minutes.

Nextcloud Server version

31

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.3

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?

None

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": [
            "***REMOVED SENSITIVE VALUE***"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "31.0.10.2",
        "overwrite.cli.url": "http:\/\/localhost",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "maintenance": false,
        "defaultapp": "",
        "loglevel": "0",
        "updater.secret": "***REMOVED SENSITIVE VALUE***",
        "theme": "",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379,
            "timeout": 1.5
        }
    }
}

List of activated Apps

Enabled:
  - activity: 4.0.0
  - app_api: 5.0.2
  - bruteforcesettings: 4.0.0
  - cloud_federation_api: 1.14.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_sharing: 1.23.1
  - files_trashbin: 1.21.0
  - files_versions: 1.24.0
  - logreader: 4.0.0
  - lookup_server_connector: 1.19.0
  - notifications: 4.0.0
  - oauth2: 1.19.1
  - profile: 1.0.0
  - provisioning_api: 1.21.0
  - recommendations: 4.0.0
  - related_resources: 2.0.0
  - serverinfo: 3.0.0
  - settings: 1.14.0
  - support: 3.0.0
  - text: 5.0.2
  - theming: 2.6.1
  - twofactor_backupcodes: 1.20.0
  - updatenotification: 1.21.0
  - user_saml: 7.0.0
  - viewer: 4.0.0
  - workflowengine: 2.13.0
Disabled:
  - admin_audit: 1.21.0
  - circles: 31.0.0 (installed 31.0.0)
  - comments: 1.21.0 (installed 1.21.0)
  - contactsinteraction: 1.12.1 (installed 1.12.0)
  - encryption: 2.19.0
  - files_external: 1.23.0
  - files_reminders: 1.4.0 (installed 1.4.0)
  - firstrunwizard: 4.0.0 (installed 4.0.0)
  - nextcloud_announcements: 3.0.0 (installed 3.0.0)
  - password_policy: 3.0.0 (installed 3.0.0)
  - photos: 4.0.0 (installed 4.0.0)
  - privacy: 3.0.0 (installed 3.0.0)
  - sharebymail: 1.21.0 (installed 1.21.0)
  - survey_client: 3.0.0 (installed 3.0.0)
  - suspicious_login: 9.0.1
  - systemtags: 1.21.1 (installed 1.21.1)
  - twofactor_nextcloud_notification: 5.0.0
  - twofactor_totp: 13.0.0-dev.0
  - user_ldap: 1.22.0 (installed 1.22.0)
  - user_status: 1.11.0 (installed 1.11.0)
  - weather_status: 1.11.0 (installed 1.11.0)
  - webhook_listeners: 1.2.0 (installed 1.2.0)

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

{"reqId":"sGsBzm35CWuZpynmopPD","level":2,"time":"2025-11-10T08:38:02+00:00","remoteAddr":"<ip_adress>","user":"--","app":"core","method":"GET","url":"/remote.php/dav/files/<username>/","message":"Login failed: '<username>' (Remote IP: '<ip_adress>')","userAgent":"curl/8.7.1","version":"31.0.10.2","data":{"app":"core"}}
{"reqId":"sGsBzm35CWuZpynmopPD","level":2,"time":"2025-11-10T08:38:02+00:00","remoteAddr":"<ip_adress>","user":"--","app":"core","method":"GET","url":"/remote.php/dav/files/<username>/","message":"Session token credentials are invalid","userAgent":"curl/8.7.1","version":"31.0.10.2","data":{"app":"core","user":"<username>"}}
{"reqId":"sGsBzm35CWuZpynmopPD","level":3,"time":"2025-11-10T08:38:02+00:00","remoteAddr":"<ip_adress>","user":"--","app":"no app in context","method":"GET","url":"/remote.php/dav/files/<username>/","message":"Exception thrown: OC\\Authentication\\Exceptions\\TokenPasswordExpiredException","userAgent":"curl/8.7.1","version":"31.0.10.2","exception":{"Exception":"OC\\Authentication\\Exceptions\\TokenPasswordExpiredException","Message":"","Code":0,"Trace":[{"file":"/var/www/html/lib/private/Authentication/TokenPublicKeyTokenProvider.php","line":152,"function":"checkToken","class":"OC\\Authentication\\Token\\PublicKeyTokenProvider","type":"->"},{"file":"/var/www/html/lib/private/Authentication/Token/Manager.php","line":121,"function":"getToken","class":"OC\\Authentication\\Token\\PublicKeyTokenProvider","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/html/lib/private/User/Session.php","line":413,"function":"getToken","class":"OC\\Authentication\\Token\\Manager","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/html/apps/dav/lib/Connector/Sabre/Auth.php","line":80,"function":"logClientIn","class":"OC\\User\\Session","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Auth/Backend/AbstractBasic.php","line":103,"function":"validateUserPass","class":"OCA\\DAV\\Connector\\Sabre\\Auth","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/html/apps/dav/lib/Connector/Sabre/Auth.php","line":191,"function":"check","class":"Sabre\\DAV\\Auth\\Backend\\AbstractBasic","type":"->"},{"file":"/var/www/html/apps/dav/lib/Connector/Sabre/Auth.php","line":105,"function":"auth","class":"OCA\\DAV\\Connector\\Sabre\\Auth","type":"->"},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Auth/Plugin.php","line":179,"function":"check","class":"OCA\\DAV\\Connector\\Sabre\\Auth","type":"->"},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Auth/Plugin.php","line":135,"function":"check","class":"Sabre\\DAV\\Auth\\Plugin","type":"->"},{"file":"/var/www/html/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"beforeMethod","class":"Sabre\\DAV\\Auth\\Plugin","type":"->"},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":456,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/var/www/html/apps/dav/lib/Connector/Sabre/Server.php","line":49,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/var/www/html/apps/dav/lib/Server.php","line":403,"function":"start","class":"OCA\\DAV\\Connector\\Sabre\\Server","type":"->"},{"file":"/var/www/html/apps/dav/appinfo/v2/remote.php","line":21,"function":"exec","class":"OCA\\DAV\\Server","type":"->"},{"file":"/var/www/html/remote.php","line":145,"args":["/var/www/html/apps/dav/appinfo/v2/remote.php"],"function":"require_once"}],"File":"/var/www/html/lib/private/Authentication/Token/PublicKeyTokenProvider.php","Line":226,"message":"","exception":{},"CustomMessage":"Exception thrown: OC\\Authentication\\Exceptions\\TokenPasswordExpiredException"}}
{"reqId":"sGsBzm35CWuZpynmopPD","level":3,"time":"2025-11-10T08:38:02+00:00","remoteAddr":"<ip_adress>","user":"--","app":"webdav","method":"GET","url":"/remote.php/dav/files/<username>/","message":"OC\\Authentication\\Exceptions\\TokenPasswordExpiredException: ","userAgent":"curl/8.7.1","version":"31.0.10.2","exception":{"Exception":"Sabre\\DAV\\Exception\\ServiceUnavailable","Message":"OC\\Authentication\\Exceptions\\TokenPasswordExpiredException: ","Code":0,"Trace":[{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Auth/Plugin.php","line":179,"function":"check","class":"OCA\\DAV\\Connector\\Sabre\\Auth","type":"->"},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Auth/Plugin.php","line":135,"function":"check","class":"Sabre\\DAV\\Auth\\Plugin","type":"->"},{"file":"/var/www/html/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"beforeMethod","class":"Sabre\\DAV\\Auth\\Plugin","type":"->"},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":456,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/var/www/html/apps/dav/lib/Connector/Sabre/Server.php","line":49,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/var/www/html/apps/dav/lib/Server.php","line":403,"function":"start","class":"OCA\\DAV\\Connector\\Sabre\\Server","type":"->"},{"file":"/var/www/html/apps/dav/appinfo/v2/remote.php","line":21,"function":"exec","class":"OCA\\DAV\\Server","type":"->"},{"file":"/var/www/html/remote.php","line":145,"args":["/var/www/html/apps/dav/appinfo/v2/remote.php"],"function":"require_once"}],"File":"/var/www/html/apps/dav/lib/Connector/Sabre/Auth.php","Line":112,"message":"OC\\Authentication\\Exceptions\\TokenPasswordExpiredException: ","exception":{},"CustomMessage":"OC\\Authentication\\Exceptions\\TokenPasswordExpiredException: "}}

Additional info

• password_invalid is set only when a request using the token is made after 5 min, not automatically by a job. Possible that the token has a cache lifetime of 5 mins?
• Upgrading from 31.0.8 → 31.0.10 and switching background jobs to AJAX makes no difference.
• The issue reproduces on a clean install with all non-core apps disabled.
• Appears to originate in PublicKeyTokenProvider.php during checkToken() / getToken(): the provider throws TokenPasswordExpiredException when it cannot verify the password hash of the token, even for permanent app tokens created via CLI.

[joshtrichards]

Are you entering a password for the target account when prompted at Enter the account password: during step 1?

[samuel-larsson]

Are you entering a password for the target account when prompted at Enter the account password: during step 1?

Sorry yes, I should've clarified that. I am entering a password in that step. In my troubleshooting, I have tried with both the actual user's password, or something random. And both using the interactive prompt and the --password-from-env flag. Because, and I might be misremembering, but it can't be empty, right?

[qhga]

We can confirm a similar behavior. We created multiple app passwords via a script. The passwords work for approximately 5 minutes and after that are no longer valid.

[pr0kium]

hi guys,
Same here on NC 32.
I am generating a token, try to connect with it immediately (in webdav) it works.
After few minutes (5), it not working anymore.
I am using a "password" when generating the token.

[pr0kium]

What i have found :

private function checkTokenCredentials(IToken $dbToken, $token) {
		// Check whether login credentials are still valid and the user was not disabled
		// **This check is performed each 5 minutes**

Still searching/trying to understand...

edit :
Related to :

• occ user:add-app-password should also work without the users login password #26563 ?
• [Bug]: add-app-password generated token are bad (and shouldn't ask for a password) #37487 ?

The "problem" i think is there (

server/lib/private/User/Session.php

Line 692 in 0580014

private function checkTokenCredentials(IToken $dbToken, $token) {

):

// If the token password is no longer valid mark it as such
		if ($this->manager->checkPassword($dbToken->getLoginName(), $pwd) === false) {
			$this->tokenProvider->markPasswordInvalid($dbToken, $token);
			// User is logged out
			return false;
		}

I ve made some tries, and effectively if the password is "the good one/user one", the app-password/token is always available after the 5 minutes.

As @schiessle said in #26563 (comment)

If a admin needs to create a app password for a user for whatever reasons (e.g. in migration szenarios) it is quite unlikely that they know the login password from the users. The provisioning API and the graphical user management allow the admin to change the users password without knowing the old one. Why should the user:add-app-password be more strict?

Second, in case of SSO no user has a login password on Nextcloud. All passwords are handled by the IDP. The current behavior of the occ command makes it completely useless in any SSO environment.

Therefore I would suggest to remove the password input/check or at least make it optional.

In my understanding, i completly agree the request to remove the pwd input.

[samuel-larsson]

I ve made some tries, and effectively if the password is "the good one/user one", the app-password/token is always available after the 5 minutes.

So it actually works if the proper password from the user in question is used? I tested this at one point and it didn't work for me, but I just tested once so it might have been something else. In any case, like @schiessle points out, we are dependent on SSO, so the users have no "login passwords" in Nextcloud that are available to use when creating a token.

In my understanding, i completely agree the request to remove the pwd input.

I agree with this too. To remove it or at least make it optional.

[pr0kium]

So it actually works if the proper password from the user in question is used?

I remade some tests, and i can confirm that :
When you create an app-pwd/token for a user giving is own password (the good one), the token dosnt expire after 5 minutes.

cc/Up @joshtrichards : Thx in advance for your feedbacks

[1Stivi]

I must add a bit more importance to that as this issue also affects connected LDAP directories which use TOTP authentication integrated into the user passwords, in our case FreeIPA. When TOTP is enabled in FreeIPA the LDAP user can authenticate using {regular-password}{totp}, so chaining both together into a single password. This works for logging in to Nextcloud initially, afterwards for creating app passwords but they stop working after the 5 minutes time period because the password in the LDAP obviously changed meanwhile.

We did extensive troubleshooting to locate the issue here and find this bug report, it's been quite a pain to be honest because we never figured how user passwords would somehow relate to app passwords, which at least suggested to us are there for exactly the purpose of supporting/simplifying MFA topics somehow for applications.

Can a relationship to any user password please be removed as it doesn't make any sense (at least to us)? Maybe define an expiration date for an app password when it is created like similar token concepts do.

[solracsf]

After digging into the Session.php code, the checkTokenCredentials function perfectly explains all the symptoms described in this issue. Here is a breakdown of what happens under the hood and why tokens are silently killed:

if ($lastCheck > ($now - 60 * 5)) { ... }

This code dictates that Nextcloud re-verifies the underlying login credentials every 5 minutes for every active session.

if ($this->manager->checkPassword($dbToken->getLoginName(), $pwd) === false) {

This is where the breakage occurs. Every 5 minutes, Nextcloud takes the decrypted password from the token ($pwd) and asks the user manager ($this->manager) if this password is still valid.

If there is even a single micro-interruption or temporary failure (e.g., an OIDC/LDAP backend timeout, a PHP-FPM restart, a temporary Redis cache desync, or a decryption glitch in PublicKeyTokenProvider), the checkPassword function returns false. Nextcloud does not treat this as a temporary backend error; it assumes the user's password has actually changed or is strictly invalid.

$this->tokenProvider->markPasswordInvalid($dbToken, $token);
return false;

As soon as the check returns false, Nextcloud immediately executes markPasswordInvalid. This function hits the oc_authtoken table in the database and flips the password_invalid column from 0 to 1.

This explains exactly why:

1. The token is not deleted (it remains visible in the user's Security Dashboard).
2. Client applications receive a permanent "Access Denied" (because the password_invalid flag is set to true).
3. It is impossible to refresh or re-authenticate the token from the client side.

If anyone wants to confirm they are affected by this exact mechanism, you can check the database immediately when a client app drops the connection:

SELECT id, name, password_invalid FROM oc_authtoken WHERE uid = 'username';

If you see password_invalid = 1 for the affected token, this specific block of code is the culprit.

To "unbrick" the token without forcing the user to log in again:
You can simply reset the value back to 0 directly in the database:

UPDATE oc_authtoken SET password_invalid = 0 WHERE id = 'TOKEN_ID';

The mobile app/sync/curl client will instantly resume syncing on its next attempt, proving 100% that this hard-fail invalidation mechanism is responsible for killing valid tokens.

When occ user:auth-tokens:add creates a token without a known user password (admin-generated, migration scenario, or SSO environment), it stores an empty or unverifiable $pwd inside the token.

Five minutes later, checkTokenCredentials decrypts this invalid $pwd and calls $this->manager->checkPassword($loginName, $pwd). Since the password is empty or unknown, this returns false, not because the user's credentials changed, but because the token was never created with a valid verifiable password in the first place.

The code then immediately marks the token as permanently invalid (password_invalid = 1), which is exactly what the reproduction steps demonstrate.