Initial session is not verified for SSO-based accounts

[tobast]

Steps to reproduce

1. Configure a Synapse server to use SSO (in my case, OIDC with Lemonldap::ng) server as its sole login method
2. Login through SSO on an account that never logged in before with Element Web (v1.11.69, crypto Rust SDK 0.7.0 (068a0af), Vodozemac 0.6.0 -- the version currently at https://app.element.io). I am able to repeatedly reproduce this step by setting up a dummy Synapse server, deleting the sqlite database and restarting the service.
3. Check your account's sessions

Outcome

What did you expect?

Your only session should be verified, as it is the case with a non-SSO account on the same server, with the same client:

In this case, the account was created using Element's "register" feature, but the outcome is the same when an account is created server-side (through the admin API) and Element is then connected.

What happened instead?

Your only session is not verified, as seen here (sorry, screenshot in French)

This forces a new user to initiate a reset process, which is not intuitive to any user new to Matrix. Element also lets you setup key backup on the server, but yields a secret that cannot be used to recover the account.

Other clients

This is not reproduced using Element Android (v1.6.16).

This is reproduced using element-desktop for Linux 1.11.69

Both FluffyChat and Cinny don't try to setup session verification at startup (as far as I've seen), hence this issue is irrelevant.

Operating system

Linux

Browser information

Firefox 127.0.2

URL for webapp

app.element.io, reproduced with locally hosted version

Application version

v1.11.69, crypto Rust SDK 0.7.0 (068a0af), Vodozemac 0.6.0

Homeserver

Synapse 1.109.0+bookworm1

Will you send logs?

Yes

[rfalkenstein]

We can reproduce this error using OIDC and keycloak. Instructing users to reset and re-verify their passphrase is very difficult. Please let us know if additional logs are needed.
Best regards

[urz-hgw]

Hi,

we have the same issue using SSO via SAML and verifying the (first) session.

I tested the following two scenarios, both times I reset the synapse server (v1.109) and started from scratch, results are identical using Element App or the latest Element web client.

Scenario 1:
Login with SSO user --> Security & Privacy --> Set Up --> Enter a Security Phrase --> Continue and Download the key.
==> Secure Backup successful

Then I select Sessions --> Verify Session --> Verify with Security Key or Phrase

I can either enter the phrase or the key file, click on "continue" and will immediately be thrown back to "Verify with Security Key or Phrase" and I can repeat this on and on in an endless loop and the session won't verify.

Then I logout from the session and login again. After the login Element asks for a security phrase, but the saved one does not work and the process is broken. I can fix this only by resetting the security key and after setting a new phrase and new file I am additionally asked to verify my account by "Use Single Sign On to continue", which I do and after that my session is finally verified, but with the newly created key.

Scenario 2:
Login with SSO user --> Sessions --> Verify session
I directly have to "Proceed with reset" since there is no key present, I enter my phrase, download the key and get a "Secure Backup successful" and here I also have to "Use Single Sign On to continue" and after that my session is verified.
After logout and login again, I'm being ask for the phrase or the key and it is accepted and my new session is immediately verified.

So in Scenario 2 everything works as it should, but in Scenario 1 the dialog to "Use Single Sign On to continue" does not appear after trying to verify my current session with the created key.

Unfortunately there are no error logs at all in synapse or element-web, only the browser log throws some errors when clicking on "continue" in scenario 1 when I am in the endless loop.

FetchHttpApi: --> GET https://my-server.de/_matrix/client/unstable/org.matrix.msc2697.v2/dehydrated_device rageshake.ts:77:16
bootstrapCrossSigning: starting 
Object { setupNewCrossSigning: undefined, olmDeviceHasMaster: true, olmDeviceHasUserSigning: true, olmDeviceHasSelfSigning: true, privateKeysInSecretStorage: true }
rageshake.ts:77:16
bootstrapCrossSigning: Olm device has private keys and they are saved in secret storage; doing nothing rageshake.ts:77:16
bootstrapCrossSigning: complete rageshake.ts:77:16
Not setting dehydration key: feature disabled rageshake.ts:77:16
FetchHttpApi: --> GET https://my-server.de/_matrix/client/unstable/org.matrix.msc3814.v1/dehydrated_device rageshake.ts:77:16
XHRGET
https://my-server.de/_matrix/client/unstable/org.matrix.msc2697.v2/dehydrated_device
[HTTP/2 404  40ms]

XHRGET
https://my-server.de/_matrix/client/unstable/org.matrix.msc3814.v1/dehydrated_device
[HTTP/2 404  38ms]

FetchHttpApi: <-- GET https://my-server.de/_matrix/client/unstable/org.matrix.msc2697.v2/dehydrated_device [83ms 404] rageshake.ts:77:16
could not get dehydrated device M_NOT_FOUND: MatrixError: [404] No dehydrated device available (https://my-server.de/_matrix/client/unstable/org.matrix.msc2697.v2/dehydrated_device)
    s errors.ts:37
    a errors.ts:66
    p utils.ts:83
    requestOtherUrl fetch.ts:333
    request fetch.ts:241
    authedRequest fetch.ts:159
    getDehydratedDevice client.ts:1681
    fetchKeyInfo SetupEncryptionStore.ts:109
    start SetupEncryptionStore.ts:78
    p SetupEncryptionBody.tsx:52
    React 8
    unstable_runWithPriority scheduler.production.min.js:18
    React 6
    componentDidMount AsyncWrapper.tsx:58
    promise callback*componentDidMount AsyncWrapper.tsx:49
    React 2
    unstable_runWithPriority scheduler.production.min.js:18
    React 4
    unstable_runWithPriority scheduler.production.min.js:18
    React 7
    reRender Modal.tsx:425
    p setImmediate.js:40
    p setImmediate.js:69
    a setImmediate.js:109
rageshake.ts:77:16
FetchHttpApi: <-- GET https://my-server.de/_matrix/client/unstable/org.matrix.msc3814.v1/dehydrated_device [84ms 404] rageshake.ts:77:16
FetchHttpApi: --> GET https://my-server.de/_matrix/client/v3/room_keys/keys?version=xxx rageshake.ts:77:16
[PerSessionKeyBackupDownloader] Got current backup version from server: 1 rageshake.ts:77:16
FetchHttpApi: <-- GET https://my-server.de/_matrix/client/v3/room_keys/keys?version=xxx [102ms 200] rageshake.ts:77:16
Checking key backup status... rageshake.ts:77:16
FetchHttpApi: --> GET https://my-server.de/_matrix/client/v3/room_keys/version rageshake.ts:77:16
FetchHttpApi: <-- GET https://my-server.de/_matrix/client/v3/room_keys/version [86ms 200] rageshake.ts:77:16
Backup version 1 still current

Hope this helps....

Best regards
Daniel

[crjo]

Hi,
We are having such issues with SSO and keys management, since many weeks, all issues are closed to point to #27455, but no update there
We are having a very bad UX and we found nothing that can leverage the difficulty, expect having users to logout and reset keys.
Regards

[mglaubitz]

Hi there, we have the same problem and very new user on our server runs into this problem since we advise our users to use the element desktop client. We are fighting against commercial tools like WhatsApp and Telegram and need a solution for this problem that works without a complicated series of steps that each user has to take.

Are you already working on this issue? What can we do to help?

Thanks in advance for your endeavors!

[urz-hgw]

It looks like this issue is solved in Element-Desktop Version 1.11.70 .. could somebody please verify this?

[rfalkenstein]

Thank you very much for this information. We rechecked with Element 1.11.70: It still didn't work. Upgrading the homeserver to v1.110, however, did the trick. I assume it has to do with: element-hq/synapse#17284. The verification is now set up upon the first login.