OIDC - implement a switch to disable OIDC account creation

[Kyrodan]

I use OIDC with many apps. Not all my OIDC-Users should automatically get a Yuvomi account.
So I would like to disable "automatic account registration" using OIDC. There is also no self-service option for user account registration.

Automatic linking for existing accounts needs to be possible with this ne switch turned on:

1. manually create account in admin panel
2. user logs in using OIDC

=> User is linked to OIDC-User and is allowed to use Yuvomi

Additional considerations:
If I create a new user in admin UI, it's required to provide a password for this user. For OIDC this is not necessary, so a user should be able to create without password and - important - this user may not use the regular Login-Form.

In this scenario it would be great to have an additional Switch to completely disable "integrated" auth - the user only has the "Login with SSO" button. Having multiple OIDC-Providers in mind, the button should be named in configuration.

In current version: if a OIDC-User is auto-generated, this user has a "fake-password-hash", so he is never allowed to login. => this works. But maybe having a blank password hash should disable login for this user (using integrated auth) completely is an improved solution.

The password-reset function also needs to be disabled. Additionally I saw a feature request to have an "invitation link" for newly created users. => this should also be considered.

For me it's also interesting to have users, which never login but can have tasks assigned (like younger children or grand parents). These tasks should then be "processed" behalf of the "assignee" => new feature request.

[ulsklyc]

Built and shipped in v2.39.0: OIDC_ALLOW_SIGNUP=false stops SSO sign-ins from creating accounts.

You named the crucial constraint yourself, and it shaped the implementation. The switch removes exactly one step, the provisioning. Everything before it stays:

1. a known sub signs in as before
2. an account you created by hand in the admin panel is still linked on the user's first SSO sign-in (the provider must report email_verified: true, or the account owner links it themselves under Settings -> Account -> Single sign-on)
3. only an identity that matches neither is turned away

Had linking gone away with the provisioning, the switch would have locked out the very person you just entered, which would have made it unusable. So your flow works: create the account, the user signs in with SSO, the two find each other.

Two details worth knowing:

• The default is true. A security switch that flips during an update is a lockout, not a switch, so existing installations behave exactly as before.
• Only the literal value false disables it. Anything else leaves provisioning on, so a typo cannot shut a household out of its own app.

A turned-away sign-in now carries its own message ("There is no account here yet for this SSO sign-in") instead of the generic "SSO sign-in failed". The generic wording was actively misleading here: the sign-in at the provider worked, the account is missing, and whoever read it went looking at their password instead of at their admin. Translated into all 24 languages.

The switch is available everywhere the other OIDC variables are: .env, Portainer compose, the Unraid template and the setup wizard. Details in installation.md.

---

What this does not cover. Your post bundles four further wishes, and they are separate pieces of work rather than parts of this switch:

1. creating an account in the admin panel without a password
2. disabling built-in authentication entirely, so only the SSO button remains
3. disabling password reset along with it
4. multiple OIDC providers, each with its own configurable button label

I would rather not let them live inside a thread whose title is now done. Could you open them as their own ideas? Number 1 and 2 belong together and are the natural next step: an account with no password today still shows a password field, and until built-in auth can be turned off, the login form stays a second way in. Number 4 is the largest by far, since the whole OIDC configuration currently assumes a single provider.

The fifth thought at the end of your post, members who never sign in but can be assigned tasks, already exists: Settings -> Administration -> Family lets you add a family member without an account. Tasks can be assigned to them and completed on their behalf. If that does not match what you had in mind, that one deserves its own thread too.

Leaving this open until those are split out.

[ulsklyc]

Correction to my last paragraph: I was wrong about members without an account, and I checked the code only after posting.

POST /api/v1/auth/users requires a password (minimum 8 characters, otherwise 400), so Settings -> Administration -> Family cannot currently create a member who has no way to sign in. Every family member is a full account. What does exist without an account is a guest in shared expenses, which is a different thing and cannot be assigned tasks.

So your fifth point stands as a real request, and it turns out to be closely tied to point 1 on my list: an account with no password is exactly what a never-signing-in member would need, and today the API refuses to create one. Worth opening as its own thread as well.

Sorry for sending you looking for something that is not there.

[ulsklyc]

I said I would leave this open until the remaining wishes were split out, and then realised it was unfair to hand you that work. I have done the splitting instead:

• Run Yuvomi with SSO as the only way in: passwordless accounts, no login form, no password reset #847 - run Yuvomi with SSO as the only way in: accounts without a password, no login form, no password reset. Your points 1 to 3 belong together, since each is a half-measure without the others. Your fifth thought, members who never sign in but can be assigned tasks, is in there too, because point 1 is its groundwork.
• Support multiple OIDC providers, each with its own button label #848 - multiple OIDC providers with their own button labels. On its own, because it is the only one that touches the data model rather than the login screen.

Both carry the open questions I would want answered before anything gets designed, and both are yours to correct if I have misread what you meant. Please do - I would rather fix the description now than build against a wrong reading later.

Closing this one: the switch in the title is released in v2.39.0.

Thanks for the report. It was precise enough to build from directly, and the constraint you named - that linking has to keep working, or the switch locks out the person you just entered - is the part that would have been easy to get wrong.

[Kyrodan]

Seems to work as expected.