(I'm pasting here the problem and question I wrote on the Matrix chat earlier today, it might interest other people)

Little question here regarding the SSO plugin: I've installed a working CryptPad instance a few months ago and I've created several users on it.
Everything works fine but now I'd like to connect it to my OIDP server (Authentik) and use it to allow my existing users to log into Cryptpad (at least partially, I know the password remains necessary to decrypt the files).

I've installed and configured the plugin, it seems to work... although when I connect with a user that exists in both Authentik and CryptPad (I mean where CryptPad's "name" == Authentik's "preferred_username") I still get the page to define a password for my user, instead of having the one to enter it.
I don't want to go further in case it would break any already existing data in CryptPad.
If I provision a new user from Authentik, I get the expected page instead, so there must be something with pre-existing users on CryptPad side I guess.
Is this scenario supported?

My sso.js is as follows

module.exports = {
  enabled: true,
  enforced: false,
  cpPassword: true,
  forceCpPassword: false,
  list: [
    {
      name: 'Authentik',
      type: 'oidc',
      url: 'https://authentik.tld/application/o/cryptpad/',
      client_id: "<ID>",
      client_secret: "<SECRET>",
      jwt_alg: 'RS256',
      username_scope: 'profile',
      username_claim: 'preferred_username',
    },
  ]
}

And replying to myself:

I think I found the missing pieces. Looking at the data/ folder I can see that there are some sso_* folders that are used for the OAuth login process.
My "test user" that I created earlier via SSO has some important JSON files in sso_user/ and sso_block/.
The first one particularly is holding and ID that is the same as the one provided by Authentik (in the sub field of the JWT).
Without this, a local user cannot "log in" via SSO and I suppose that if I carry the process through, I'll just end up with a different user that will share the same name but will have a different encryption key, and thus, a totally different profile.

Which means, if I'm not mistaking, that logging in locally will load the local profile, and logging in from the SSO will load the SSO profile.

IMHO it should be possible to combine both approches and switch to one or the other with a dedicated setting.

Also one idea would be to use the email as the common identifier instead of relying on the username or the generated ID returned by the OIDP, but it would be hard not to break retro-compatibility.