Logintoken are Invalidated 21.0.1

[newhinton]

After updating to 21 from 20, external applications cannot access nextcloud anymore. Shortly after they were set up (Either via the Loginflow, or manually setting up tokens and inserting them in the respective app) they are getting disabled and the corresponding app is beeing logged out or recieves "Unauthorized" errors. The Logmessage is not providing a reason why a token was invalidated. The webui works as intended.

Edit: Forum

Steps to reproduce

1. Set up new Apptoken
2. Enter token and use it
3. Get Unauthorized errors, and password_invalid is set to 1 in the database.

Expected behaviour

Login should not be invalidated.

Actual behaviour

Token gets immediately invalidated.

Server configuration

Operating system:
Ubuntu 20.04

Web server:
Apache

Database:
Msql

PHP version:
7.4.3

Nextcloud version: (see Nextcloud admin page)
21.0.1.1

Updated from an older Nextcloud/ownCloud or fresh install:
Updated from 20.0.9

List of activated apps:

App list

Enabled:
  - activity: 2.14.3
  - admin_audit: 1.11.0
  - apporder: 0.12.0
  - bookmarks: 4.1.0
  - bruteforcesettings: 2.1.0
  - calendar: 2.2.0
  - cloud_federation_api: 1.4.0
  - contacts: 3.5.1
  - contactsinteraction: 1.2.0
  - cookbook: 0.8.4
  - dav: 1.17.1
  - federatedfilesharing: 1.11.0
  - files: 1.16.0
  - files_pdfviewer: 2.1.0
  - files_rightclick: 1.0.0
  - files_sharing: 1.13.1
  - files_trashbin: 1.11.0
  - files_versions: 1.14.0
  - logreader: 2.6.0
  - lookup_server_connector: 1.9.0
  - notes: 4.0.4
  - notifications: 2.9.0
  - oauth2: 1.9.0
  - oidc_login: 1.7.1
  - password_policy: 1.11.0
  - photos: 1.3.0
  - previewgenerator: 3.1.1
  - privacy: 1.5.0
  - provisioning_api: 1.11.0
  - quickaccesssorting: 1.1.2
  - quota_warning: 1.10.0
  - ransomware_protection: 1.10.0
  - richdocumentscode: 6.4.705
  - settings: 1.3.0
  - sharebymail: 1.11.0
  - spreed: 11.1.2
  - text: 3.2.0
  - theming: 1.12.0
  - theming_customcss: 1.8.0
  - twofactor_backupcodes: 1.10.0
  - updatenotification: 1.11.0
  - viewer: 1.5.0
  - workflowengine: 2.3.0

Nextcloud configuration:

Config report

bruteforce is disabled

Are you using encryption: no

Are you using an external user-backend, if yes which one: Single Sign on via Keycloak

Client configuration

Nextcloud Apps (Linux Desktop and Android), DAVx5

Logs

Web server error log

Web server error log

"PROPFIND /remote.php/dav/calendars/A/B/ HTTP/1.1" 401 5669 "-" "DAVx5/3.3.9-ose (2021/02/27; dav4jvm; okhttp/4.9.1) Android/11"

Nextcloud log (data/nextcloud.log)

Nextcloud log

Warning | core | Login failed: 'X' (Remote IP: 'Y')

[userofgithub023897]

Same problem as already described by newhinton.
After the update to Nextcloud 21 there is a problem with the login to Nextcloud, via web browser and tokens .

Actual behaviour

Web browser login

• Login via web interface works as usual. I use FIDO2 and TOTP which works fine via web browser.
• After some time there is an auto log off

Third Party Apps

• Login to web interface works fine to create tokens
• Token creation is possible
• Token works for some time within different third party apps, like Thunderbird, Joplin, iOS Calendar app
• After some time the following happens

1. automatic log out from web interface
2. Login via previously created token is no longer possible. All connected apps show an error message.

This error exists even for older tokens which were created with an older Nextcloud version.
So on all devices it is not possible to connect via Token to a Nextcloud instance.

Nextcloud Desktop-Client (Version 3.1.3)
After the update to Nextcloud 21.0.1 the client lost the connection to Nextcloud.
The verification via web bowser worked fine and the client got a connection again.
The client lost the connection after some time to Nextcloud again.

You can go through the hole process over and over again with always the same results.

Server configuration

Operating system:
Raspbian GNU/Linux 10 (buster)

Web server:
Apache/2.4.38 (Raspbian)

Database:
MariaDB 10.3.27

PHP version:
PHP 7.3.27

Nextcloud version:
Nextcloud 21.0.1

Updated from an older Nextcloud/ownCloud or fresh install:
older Version of Nextcloud

Where did you install Nextcloud from:
Web based update process

List of activated apps:
sudo -u www-data php occ app:list

Enabled:

• accessibility: 1.7.0
• activity: 2.14.3
• bookmarks: 4.1.0
• calendar: 2.2.0
• cloud_federation_api: 1.4.0
• comments: 1.11.0
• contacts: 3.5.1
• contactsinteraction: 1.2.0
• dashboard: 7.1.0
• dav: 1.17.1
• event_update_notification: 1.2.0
• federatedfilesharing: 1.11.0
• federation: 1.11.0
• files: 1.16.0
• files_pdfviewer: 2.1.0
• files_rightclick: 1.0.0
• files_sharing: 1.13.1
• files_versions: 1.14.0
• files_videoplayer: 1.10.0
• firstrunwizard: 2.10.0
• logreader: 2.6.0
• lookup_server_connector: 1.9.0
• nextcloud_announcements: 1.10.0
• notifications: 2.9.0
• oauth2: 1.9.0
• password_policy: 1.11.0
• photos: 1.3.0
• privacy: 1.5.0
• provisioning_api: 1.11.0
• ransomware_protection: 1.10.0
• recommendations: 1.0.0
• serverinfo: 1.11.0
• settings: 1.3.0
• sharebymail: 1.11.0
• survey_client: 1.9.0
• systemtags: 1.11.0
• tasks: 0.13.6
• text: 3.2.0
• theming: 1.12.0
• twofactor_backupcodes: 1.10.0
• twofactor_totp: 6.0.0
• twofactor_u2f: 6.1.0
• updatenotification: 1.11.0
• user_status: 1.1.1
• viewer: 1.5.0
• weather_status: 1.1.0
• workflowengine: 2.3.0

Are you using encryption: no

Nextcloud log

The log shows tons of such messages.

Warning core Login failed: ''
Warning core Renewing session token failed

[daniel-odrinski]

Just wanted to add that I noticed this happen only when upgrading from 21.0.0.18 to 21.0.1.1. I hope this narrows things somewhat.

[ririsoft]

Do you have any workaround to get Android and Desktop client applications work until this is fixed ?

[Weasy666]

Might it possibly have something to do with #25460 and its backport to 21.0.1 #25571?

[aeisen]

I'm seeing the exact same behavior as userofgithub023897 on the latest Docker image, but only for LDAP-authenticated users. The LDAP setup has been working through many Nextcloud versions and all tests on the LDAP / AD Integration page are still successful. LDAP-authenticated users can log in (web and apps), but are thrown out after a couple of minutes. My recurring log entries read:

Warning user_ldap Configuration Error (prefix s01): either no password is given for the user agent or a password is given, but not an LDAP agent
Warning user_ldap Bind failed: 49: Invalid credentials
Warning core Login failed:

Hope it helps narrowing this down.

[daum3ns]

im facing exactly the same behavior as @userofgithub023897 describes. (also with 21.0.1)
i have enabled automatic updates so i guess it was also a small step like @DanWiseProgramming s case..

[agentrigby]

I'm also seeing similar behaviour, but for me, it seems that logging into a new device which requires an app password will log me out of other devices.

i.e. I use DAVx5 and the Nextcloud app on my phone, and if I log in to one, it logs me out of the other. This also seems to reflect on my Desktop client too, where logging in there will log me out of my phone.

This doesn't appear to affect logging in via the web interface at all, as I can use that without it affecting whatever application is currently logged in.

Edit
I've been able to mitigate this by logging in on my desktop client, then using the same app password for DAV and the Nextcloud app on my phone, and so far, all 3 clients appear to be working without it complaining. It looks like there's a limit to the number of active app passwords you can have somehow.

I'll update this if any of my clients decide to stop working.

[newhinton]

@agentrigby How did you extract the apppassword from the desktopclient?

[userofgithub023897]

It looks like the issue only occurs for users that have log in via web interface.

Other users that haven´t logged in to Nextcloud via web browser since the update to 21.0.1 are still able to use their tokens on their devices and for their apps. At least there were no complaints about any login errors until now.

The log only shows the error messages for users that have logged in via web interface:
Warning core Login failed:
Warning core Renewing session token failed

[agentrigby]

@newhinton Not sure if it's allowing 2 sessions on my install, or different ways of logging in are treated differently.

I was able to login to the desktop client and use an app password for DAV without any issues, but the moment I logged in on the mobile app with my standard credentials, it broke both the desktop app and DAV.

Just been doing a bit more testing, and it seems whenever I login with a third session, it kicks the oldest one out. i.e. If I login via the web browser, it breaks the oldest session (DAV), leaving the 2 newer sessions active. When I generate a new app password, it breaks my desktop app, but leaves my web session active, then when I sign in again with my desktop app, it logs me out of my web session.

[osm-frasch]

Here nearly the same. There seems to be a problem with users who use security keys for login.

We have a lot of Yubico Fido2/Webauthn keys in use. ==> They are logged out of the system after a few minutes.

(Warning | core | Login failed:...)

The security keys are configured as Webauthn + U2F.
This has now worked great for half a year

Users with TOTP login as 2nd factor are not affected.

This is a big problem for us as we have a number of users with Fido2 access.

[nolexio]

I have a smiliar issue. I started migrating my user from normal login + otp to keycloak based login via social login. I didn't realize that that users are getting logged out, but now that I've read this issue it's actually exactly like that. I do also use DAVx5 to synchronize my calendar and contacts, but whenever I use the webinterface I get logged out of DAVx5 and so on.

[flo90]

I can see the same issue if I use FIDO2 for login, but there is another strange behavior. If I reconnect my desktop clients using the login flow with my password, everything is fine. If I login into the webinterface using my password, still, everything is fine. But after login with FIDO2, all clients including the web session itself is logged out after some time.
If I close the desktop client before I login with FIDO2 and after a few minutes, I login with my password before I open the desktop client again the client keeps the session.
So it seems that the registered sessions become valid again after a login with a password.
Thus using a username and a password for login seems to circumvent the issue.

[osm-frasch]

Thus using a username and a password for login seems to circumvent the issue.

For security reasons, we have coupled the login (username/password) with TOTP as a 2nd factor. These users have no problems logging in and staying logged in. Only very few in our education centre use the desktop client. For example, I had to log in again with the desktop client. This way everything works.

All users with security keys can log in but are kicked out after a few minutes. It's a drama

[daum3ns]

Thus using a username and a password for login seems to circumvent the issue.

the problem in my case for example is, that i don't really "know" the password because its very long and random.. i mean its kept somewhere in an offline storage of course... but using username and password is not really a handy option.. and breaks my security concept... thats the whole point of the fido2 key..

[userofgithub023897]

As described by @flo90 and @osm-frasch the error might be related to FIDO2 login procedure.

I logged in to web interface via TOTP instead of using the hardware token and created completely new tokens for my devices and apps. These newly created tokens work for hours now without any problems.

Afterwards, I logged in to Nextcloud web interface using TOTP instead of FIDO2 to check if the tokens will be set automatically invalid which is not the case.

Until now I haven´t any issues with this workaround. Everything works fine.

So maybe the problem is not directly related to Nextcloud but only to the app "Two-Factor U2F". (https://apps.nextcloud.com/apps/twofactor_u2f)

[klatka]

I am experiencing the same errors described by @newhinton without using TOTP or FIDO2 but OIDC and LDAP Backend.

All my app passwords became invalid after the upgrade. Newly created app passwords cannot be used ("unauthorized error").
Like @agentrigby described all the different apps that used their own app passwords stopped working.

Using different sync clients at the same time all of them are disconnected after some minutes.

@userofgithub023897 Maybe there is also an error in the app you mentioned but I don't think that the original issue is caused by this.

[newhinton]

The normal password works with clients aswell, using DavX5 with the default login-password allows the client to sync. This only works without 2FA.

[osm-frasch]

Either way,...is the solution already being taken care of? It is a big problem

[osm-frasch]

Regarding the Fido2 problem: I noticed that whenever I changed the chat room in the Talk app, I was immediately logged out. If I was not active in the other apps, e.g. file directory, I was logged out after about 2 minutes.

We have activated U2f on our security keys (Yubico) in addition to webauthn/Fido2. As a temporary solution to the problem, it helps to delete the webauthn/Fido2 authentication in the security settings of the account and only use the U2f authentication on the stick.

This then works perfectly...but does not solve the basic Fido2 problem.

[ririsoft]

All my users are connecting to Nextcloud through SSO (Keycloak + pulsejet/nextcloud-oidc-login). Having them falling back to a dedicated nextcloud password is not an option unfortunately. They can still access to nextcloud web, but mobile/desktop apps are not usable anymore due to deconnection issues already described above.

Is there a change in Nextcloud 21 API that should be reported to pulsejet/nextcloud-oidc-login or this is 100% a Nextcloud server bug please ?

[Starbix]

All my users are connecting to Nextcloud through SSO (Keycloak + pulsejet/nextcloud-oidc-login)

I use the exact same setup and NC 21.0.1 introduced this problem to my server as well

[h4ndi]

I've got the same issue. I'm using Social Login App with OAuth2 connection to Mailcow.

[daniel-odrinski]

Workaround whilst this gets fixed

Explanation: It seems that the commit linked below is the only change that was made to app passwords. I tracked this down from comparing the changes between 21.0.0 and 21.0.1. The lines below were removed, which seems to force app password renewals on each login. The workaround consists of simply reverting this change manually.

Re-add the following lines after line 416:

		if (!$this->mapper->hasExpiredTokens($uid)) {
			// Nothing to do here
			return;
		}

in lib/private/Authentication/Token/PublicKeyTokenProvider.php on your local Nextcloud installation.

Whilst not the ideal way to solve this issue (since that commit was intended to fix a different issue), at least your Nextcloud's app passwords will stop getting revoked until either Nextcloud or the third-party Authentication plugins get updated with a fix. Make sure to restart all services/Docker containers which relate to Nextcloud after applying this workaround.

I tested this on my Nextcloud 21.0.1.1 installation and it seems to be working correctly, as before upgrading to 21.0.1.1 which broke app passwords for me. I tested it by revoking my current app passwords, creating new ones, logging in using aforementioned app passwords, then logging out and logging back in several times through the Web GUI. After that I check whether the app passwords were invalidated or still working. In my case, after the fix, they are still working correctly. I use pulsejet's nextcloud-oidc-login plugin, so YMMV (though I don't expect it to).

Source: 0ea266e#diff-e75921bd09f4308ffa271ad59d43378719bf6ce5108a730708e7557f87a1e84aL417

[pulsejet]

This is an issue with Social Login and nextcloud-oidc-login, since we just supply a blank password to the login hooks, which is going to break stuff. pulsejet/nextcloud-oidc-login@3a50a43 should hopefully fix the issue, by supplying the session token to the hooks.

Someone please try this and revert (note you need to use the nc19 branch for lower than Nextcloud 19).

[ririsoft]

This is an issue with Social Login and nextcloud-oidc-login, since we just supply a blank password to the login hooks, which is going to break stuff. pulsejet/nextcloud-oidc-login@3a50a43 should hopefully fix the issue, by supplying the session token to the hooks.

Someone please try this and revert (note you need to use the nc19 branch for lower than Nextcloud 19).

Thank you @pulsejet. I upgraded to pulsejet/nextcloud-oidc-login 2.0.1 (and removed the workaround above). I tested my Android Apps (Notes, Files and Davx5) and they work fine now. I only had to relogin with the "Nextcloud Files" application, not the others.

I will do further testing with the desktop apps tonight and report issues if any.

Thanks a lot for your quick upgrade.

[newhinton]

It seems the issue seems to be fixed with the appupdate. Thanks @pulsejet!

[son1c]

I don't use the plugin from pulsejet and have the issue.
It seems to be a general issue with FIDO2.

So reopening would be nice.

[osm-frasch]

I am not sure, should a new bug report about the Fido2 thing be created at this point now. I was referred to this place in the Support Forum because there seemed to be a connection to this bug report.

[daum3ns]

why is this issue closed? this isn't solved... we don't use the plugin and the error still exists...

[nolexio]

why is this issue closed? this isn't solved... we don't use the plugin and the error still exists...

I can confirm. The problem still exists. I deactivated Social Login yesterday, as the system was not really usable anymore.

[osm-frasch]

The webauthn/Fido2 problem also still exists. I wonder. These problems are general and should be solved quickly.
Should a separate bug report be created for this? I was previously referred to this post,...thought it was all related?

[newhinton]

The original problem seems to be a change in the nextcloud-api, which broke apps using the old api. The pulsejet/nextcloud-oidc-login app fixed that, but the webauthn app does not seem to have recieved an update.

This holds true for social login aswell, those issues need to be resolved in the respective apps and not the server.

Please open issues in their repositories so that the maintainers can update their apps

[osm-frasch]

We do not use the stand-alone "Twofactor Webauthn app".
Webauthn/Fido2 is already integrated in Nextcloud since version 19.

[newhinton]

Ah sorry, i was under a different impression. I think it would be advisable to create a new issue, specifically for Webauthn/Fido2, as not to confuse underlying issues. (Ah i see, you just did that)

[osm-frasch]

All those affected by the Fido2 issue should post their additional info in the new bug report (#26806) or give a thumbs up to draw attention to the problem.

[tuxcrafter]

This may be an separate issue since I have found people having this issue since 2018. I am using an external LDAP that users password+otp. So the password / bind can only be used once to validate. However the user is getting logout after about 5 minutes with the following Bind failure.

Can someone update the LDAP module to use the admin bind for secondary lockups and only use the user bind to validate the users credentials once?

I am still using version 20.0.9

I am using default settings for these settings:
remember_login_cookie_lifetime
session_lifetime
session_keepalive

{"reqId":"YJFkTy9kZ@IUeZPiPtMCfwAAAY0","level":2,"time":"2021-05-04T17:12:15+02:00","remoteAddr":"192.168.40.29","user":"t.user","app":"user_ldap","method":"PROPFIND","url":"/remote.php/dav/files/t.user/Organization","message":"Bind failed: 49: Invalid credentials","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0","version":"20.0.8.1"}

{"reqId":"YJFkTy9kZ@IUeZPiPtMCfwAAAY0","level":2,"time":"2021-05-04T17:12:16+02:00","remoteAddr":"192.168.40.29","user":"t.user","app":"core","method":"PROPFIND","url":"/remote.php/dav/files/t.user/Organization","message":"Login failed: 't.user' (Remote IP: '192.168.40.29')","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0","version":"20.0.8.1"}

[tombou]

In my case, I've updated from 20.0.x to 21.0.5 and I've saw a big increase of the load on the database from this kind of request. I've injected the code as the fix suggest and I got back to normal load on the db. I don't use any third party apps, just app password and normal auth most of the time from webdav client.

Perhaps, a lot of the sync connected are still on the 2.x.x version, so it may try to creates token at every poke on the server.

Thanks for the temporary fix!

[chris246]

I'm observing the same issue with Nextcloud 22.2.3, Ldap Backend 1.12.1, oidc_login 2.1.0 and Keycloak as IDP:
Nextcloud Desktop Users are logged out in <1h after logging in.

I did not yet try the fix suggested by @DanWiseProgramming

[cpm1]

I have a bog standard Nextcloud 24.0.2 installation without any special plugins or auths running and implemented the suggested workaround from #26502 (comment) some hours ago (obviously at the correct position, the given line number is not valid anymore).

As far as I can tell, it just works fine without creating a zillion authtokens anymore. Of course I cleaned the database table before testing.

I'm not sure if re-adding this check in updatePasswords() has any negative side-effects, but at least it definitely solves the issue of duplicated authtokens.

[kartoffelheinz]

We are still running into this issue, even with latest 24.0.4. Produces HUGE amounts of garbage data if mysql binary logging is enabled (which is kinda mandatory if you like your data). This needs to be fixed properly once and for all.

[dominalien]

OMG, this was driving me crazy for months. Logging in from my computer was taking almost 2 minutes (!) and I was unable to log in the app on my iPhone at all.

The workaround above fixes it all right up, the line number is, however, not correct any more. As mentioned, the file to edit is lib/private/Authentication/Token/PublicKeyTokenProvider.php and the code has to be added to the function updatePasswords like this:

public function updatePasswords(string $uid, string $password) {
		$this->cache->clear();

		if (!$this->mapper->hasExpiredTokens($uid)) {
			// Nothing to do here
			return;
		}

A login now takes a couple of seconds. Result!

[apio-sys]

Recently had this very same issue (ie. desktop client keeps signing out after ~2 hours and would need manual reauth). This occurred after U/G from 25.0.12 > 27.1.3 and PHP 7.4 > 8.2. Nobody seems to be able to give a real solution despite the numerous questions I read on the subject. I applied your workaround above @dominalien and this "works" for me. This issue shouldn't be closed really.

[apio-sys]

In fact no, the following day, the problem is back... I shall open a new case that would hopefully get more attention.