Allow setting up a password after OIDC account creation. (Same for WebAuthn, which does not work; filed separately)
Feature request
Which Nextcloud Version are you currently using: (see administration page)
- [Nextcloud Hub 9] (30.0.12)
- OpenIDC 7.3.2
Is your feature request related to a problem? Please describe.
- Allow optional setting of password even after account creation by OIDC
- Problem to be solved: OIDC-Accounts do not allow to set up a password, not even by Admins
Describe the solution you'd like Describe alternatives you've considered
- Several use cases require (now and then) that users can also login with their e-mail and password
- I tested the following is working, but I don't like the workaround:
- As Admin, add manually an account for a new user X and give the Account name =
OIDCLOGINPREFIX-<sub>. - For this trick, you as Admin need to know the
<sub>. - Set up a start password for the new user X
- When user X
subcomes with OIDC, OIDC logs into the correct account. - User is now able to login either by OIDC or by e-mail (alternatively
OIDCLOGINPREFIX-<sub>) and their password. - User is able to change the password
Additional context I wish the OIDC App to allow setting a password even when no password has been assigned before the first OIDC-account-connect. The described trick works, but is ugly to perform and requires admin work.
See also https://github.com/nextcloud/user_oidc/issues/1189
The workaround does sound ugly, for sure, but I'm not sure if it's a good idea for NC to overwrite a user's credentials from the IdP either. If anything, I think the password should be updated on the IdP side, but perhaps @julien-nc has other ideas.
Just allow, as admin-settable option **), the setup of an optional password. It works perfectly in parallel to OIDC login, then.
In MediaWiki *), we do the same. If enabled, it allows users to login to their accounts, once these are created by initial OIDC login, without OIDC, i.e. on other devices.
*) https://www.mediawiki.org/wiki/Extension:OpenID_Connect
**) option, because this opening of a loophole may not be suited for all NC installations, environments, companies. Personally, I like this way very much and implemented this for wikis with > 1000 users.