[Bug]: Session revoke is useless (no-op) with session authenticated via OIDC

[thlehmann-ionos]

⚠️ 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

When revoking another browser's session that was authenticated via OIDC, the user with the other browser will go through the OIDC authentication process, creating a new Nextcloud session.

This renders the revocation useless in case of OIDC with persistent session, as they will immediately be authenticated again without having to confirm their credentials and be logged in at Nextcloud.

To the user it looks like the revocation of the session did not work. However, in the Devtools one can observe, that the user received a 401 error and went through the usual authentication process.

Steps to reproduce

Preconditions:

• Nextcloud configured with OIDC
• Login via OIDC

Steps:

1. Login into Nextcloud with browser A and go to files
2. Create a folder
3. Login into Nextcloud with browser B with the the same user and go to files
4. Go to Settings / Security in browser B
5. Under Devices & sessions "revoke" the session of browser A
6. In browser A navigate into the created folder
7. Actual:
   • Get a 401 error is shortly visible after navigation
   • A reload occurs
   • One ends up logged in
8. Expected: the user in browser A will be logged out

Expected behavior

The user in browser A will be logged out, ideally also at the authentication provider by sending them through the OIDC logout process.

Nextcloud Server version

31

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.3

Web server

Apache (supported)

Database engine version

SQlite

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": {
        "debug": true,
        "allow_local_remote_servers": true,
        "overwriteprotocol": "http",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "sqlite3",
        "version": "31.0.6.2",
        "overwrite.cli.url": "http:\/\/localhost",
        "updater.release.channel": "git",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "theme": "",
        "loglevel": 2,
        "maintenance": false
    }
}

List of activated Apps

Enabled:
  - cloud_federation_api: 1.14.0
  - comments: 1.21.0
  - 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_reminders: 1.4.0
  - files_sharing: 1.23.1
  - files_trashbin: 1.21.0
  - files_versions: 1.24.0
  - lookup_server_connector: 1.19.0
  - oauth2: 1.19.1
  - profile: 1.0.0
  - provisioning_api: 1.21.0
  - settings: 1.14.0
  - sharebymail: 1.21.0
  - systemtags: 1.21.1
  - theming: 2.6.1
  - twofactor_backupcodes: 1.20.0
  - updatenotification: 1.21.0
  - user_oidc: 7.2.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
  - testing: 1.21.0
  - user_ldap: 1.22.0

Nextcloud Signing status

Nextcloud Logs

Additional info

Network conversation

> PROPFIND http://localhost:8080/remote.php/dav/files/3890df07-9654-4705-b323-2c8d84f22b25/New%20folder/
< 401 Unauthorized

> GET http://localhost:8080/index.php/apps/files
< 401 Unauthorized

The session was correctly invalidated, yet we'll next send the user through the authentication process ...

> GET http://localhost:8080/index.php/login?redirect_url=%2Findex.php%2Fapps%2Ffiles%2Ffiles%2F43%3Fdir%3D%2FNew%2520folder
< 302 Found ; Location = 
/index.php/apps/user_oidc/login/1?...

> GET http://localhost:8080/index.php/apps/user_oidc/login/1?redirectUrl=http://localhost:8080/index.php/apps/files/files/43?dir%3D/New%2520folder
< 303 See Other ; Location = http://localhost:8079/realms/mcve/protocol/openid-connect/auth?...

> GET http://localhost:8079/realms/mcve/protocol/openid-connect/auth?...
< 302 Found ; Location = http://localhost:8080/index.php/apps/user_oidc/code?...

Format: line by line request (>) and response (<), then an optional comment on the dialog.

Reproducer

For reproduction you can re-use this MCVE (for another issue), which provides the necessary setup: https://github.com/IONOS-Productivity/mcve-nextcloud-logout-oidc-fails/tree/v1.0

It contains:

• A container to run Nextcloud in
• Configurations and install scripts

[thlehmann-ionos]

Thoughts on how to fix this

Instead of just revoking the session (deleting it from the database) it should be marked as revoked.

Nextcloud would then be able to detect that a session was revoked and could send the user actively to the end session endpoint instead of through the authentication process.

By just deleting the session Nextcloud could not distinguish unauthenticated with legitimate intent to authenticate from need to actively logging out.

[sorbaugh]

cc @julien-nc

[julien-nc]

@thlehmann-ionos Thanks for the detailed issue description.
To add some terminology, what is lacking is the frontchannel logout when a NC user session is invalidated/revoked.
I am not sure yet it is possible to do what you describe.

It might be possible for user_oidc to know when a NC session is revoked. Then, ideally we could trigger the frontchannel logout just like if the user had logged out with the logout button.

user_oidc stores the Oidc sessions in the database, each entry contains

• some Oidc attributes: sid, sub, iss
• the auth token ID (this is what is being invalidated in the security settings)
• the related Php session ID

This is not enough, we would need to store the provider ID (to know where to send a request to end the IdP session) and maybe the login ID token.

My concern is that when being authenticated as the user B, the browser has a different IdP session. We can't simply redirect the user to an "IdP logout page" like we do with the classic NC logout. If we do that, the IdP session of user B will get destroyed, not the one of user A.
We need to check if the endSessionEndpoint can be used without having the IdP session.
It might be possible because there is a id_token_hint optional parameter for this endpoint. It might be enough for the IdP to know which session to terminate on its side.

[thlehmann-ionos]

Thanks for your quick response and the background explanation.

We can't simply redirect the user [B] to an "IdP logout page" like we do with the classic NC logout.

(Referencing my initial issue: user B revokes session A and assuming you kept the same variables. Clarification in angular brackets.)

Yes, that's true.

My idea was, to send the user of session A to the end session endpoint in the moment they try to interact with the session.

User B                            User A

- revokes session A

...

                                  - some activity
                                  - detects session is not valid
                                  - checks for session invalidity reason (=revoked)
                                  - redirects user to end session endpoint
                                  - user is redirected to IdP to end session and ends the session

[julien-nc]

@thlehmann-ionos The problem with your approach is that once the session of browser A is revoked, loading any page in browser A will result in seeing the login page, nothing in user_oidc is triggered. So it seems impossible to know at this moment that there was a living session that was revoked.

We are investigating to find a satisfying solution here. It might take some time.

[julien-nc]

Here is what we went for:

• Add an event in Nextcloud's core when an authentication token is invalidated (this happens when revoking a session, cleaning up old sessions etc...)
• Listen to this event in user_oidc
• Get the Oidc session related with the invalidated NC token
• Send a request to the end_session_endpoint of the related Oidc provider (It is possible to end any provider session by passing the login ID token that was obtained on login)

So the termination of the Oidc session on the provider side is immediate when a NC session is invalidated.

This new server event will be available in Nextcloud 32. So this new user_oidc "feature" will only work with Nextcloud 32.

Here are the related PRs:

• Dispatch new event when invalidating an authentication token #54545
• Handle session token revocation user_oidc#1181