If I'm correct SSO bypasses that check. But not sure from the top of my head. @Timshel maybe knows this better?
<!-- gh-comment-id:4178312873 -->
@BlackDex commented on GitHub (Apr 2, 2026):
If I'm correct SSO bypasses that check. But not sure from the top of my head. @Timshel maybe knows this better?
Yes the idea is to remove the need to invite users one by one for the configured provider.
The signups_domains_whitelist is still applied but signups_allowed is ignored.
It's not really intended to use with providers where you do not control the user list, it becomes kind of useless since the main feature are to remove the need for invitation and allow access revocation at the provider level if sso_only is used.
<!-- gh-comment-id:4178445098 -->
@Timshel commented on GitHub (Apr 2, 2026):
Yes the idea is to remove the need to invite users one by one for the configured provider.
The `signups_domains_whitelist` is still applied but `signups_allowed` is ignored.
It's not really intended to use with providers where you do not control the user list, it becomes kind of useless since the main feature are to remove the need for invitation and allow access revocation at the provider level if `sso_only` is used.
Alright I see.
Not ideal, I hoped to use the Google OAuth same as I use for other self-hosted apps but they do allow control of limiting user creation to only invited or created only.
I think in this scenario I will disable it. Maybe it will be considered as a feature in the future.
<!-- gh-comment-id:4178490404 -->
@capsel22 commented on GitHub (Apr 2, 2026):
Alright I see.
Not ideal, I hoped to use the Google OAuth same as I use for other self-hosted apps but they do allow control of limiting user creation to only invited or created only.
I think in this scenario I will disable it. Maybe it will be considered as a feature in the future.
Maybe I'm missing something but if you still want to invite users I don't understand what OAuth is bringing you ?
It does open the possibility of not sending/storing the master password to/in the server but at the moment this is not supported.
It might become possible some day since Bitwarden is adding features removing the need for master password (Ex: trusted devices) but I don't know how it interacts with the part of the application/server which used to require it (Ex: adding a 2FA device).
<!-- gh-comment-id:4178740513 -->
@Timshel commented on GitHub (Apr 2, 2026):
Maybe I'm missing something but if you still want to invite users I don't understand what OAuth is bringing you ?
It does open the possibility of not sending/storing the master password to/in the server but at the moment this is not supported.
It might become possible some day since Bitwarden is adding features removing the need for master password (Ex: [trusted devices](https://bitwarden.com/help/about-trusted-devices/#impact-on-master-passwords)) but I don't know how it interacts with the part of the application/server which used to require it (Ex: adding a 2FA device).
Maybe I'm missing something but if you still want to invite users I don't understand what OAuth is bringing you ?
It does open the possibility of not sending/storing the master password to/in the server but at the moment this is not supported. It might become possible some day since Bitwarden is adding features removing the need for master password (Ex: trusted devices) but I don't know how it interacts with the part of the application/server which used to require it (Ex: adding a 2FA device).
Ohhh yeah, I didn't realise you can't hide the master password requirement when using sso.
You are right at this point in time there is no benefit.
<!-- gh-comment-id:4178768966 -->
@capsel22 commented on GitHub (Apr 2, 2026):
> Maybe I'm missing something but if you still want to invite users I don't understand what OAuth is bringing you ?
>
> It does open the possibility of not sending/storing the master password to/in the server but at the moment this is not supported. It might become possible some day since Bitwarden is adding features removing the need for master password (Ex: [trusted devices](https://bitwarden.com/help/about-trusted-devices/#impact-on-master-passwords)) but I don't know how it interacts with the part of the application/server which used to require it (Ex: adding a 2FA device).
Ohhh yeah, I didn't realise you can't hide the master password requirement when using sso.
You are right at this point in time there is no benefit.
I wanted to follow up on the behaviour of SIGNUPS_ALLOWED=false specifically when paired with an SSO_ONLY configuration using a public Identity Provider (like Google OIDC).
The current architecture presents a security ambiguity for self-hosters who want to leverage a public IdP strictly for identity verification (pre-authentication). If a service is exposed to the public internet with SSO_ONLY=true, a malicious actor with a standard @gmail.com address can authenticate against Google, and Vaultwarden will automatically provision them a new account, completely bypassing SIGNUPS_ALLOWED=false.
While managing authorised user lists is easily handled upstream in self-hosted IdPs (like Authelia or Authentik), it is not natively possible when using standard Google OIDC (Non-Google Workspace) for a small family setup. This forces users into the non-obvious workaround of setting a non-existent domain in SIGNUPS_DOMAINS_WHITELIST just to stop automatic provisioning, which I found by digging around in the GitHub issues.
This behaviour of using SSO_ONLY and the functionality of SIGNUPS_ALLOWED being ignored was not not explained in the Envionrment Templates I predominantly used when configuring Vaultwarden in K3S. I interpreted this as SIGNUPS_ALLOWED=false being explicit, like a lock-down for the entire Vaultwarden server.
To tighten this up and make the behaviour less ambiguous, I would like to propose the following options:
Enforce SIGNUPS_ALLOWED=false globally: Ideally, if sign-ups are disabled, an OIDC login should only succeed if the corresponding email already exists in the Vaultwarden database, regardless of successful IdP authentication. If it is the case that enabling this behaviour impacts IdP managed user access patterns when set to true (i.e. by exposing a basic non SSO sign-up pathway), then I can understand why this logic is in situ even if it's not explained clearly.
Introduce an explicit toggle: If the current behaviour is required for backward compatibility or managed IdP setups, we could introduce something like SSO_AUTO_SIGNUPS_ALLOWED=true/false (defaulting to true). This explicitly decouples OIDC provisioning from the standard sign-up flow, and would provide a mechanism for completely disabling sign-up with authorisation based only on the existing database members when using simple OIDC providers.
Documentation: At a minimum, if this behaviour is working as intended, the documentation should explicitly state that SIGNUPS_ALLOWED=false is ignored under SSO/OIDC configurations and in SSO_ONLY regimes, and that users utilising public IdPs must leverage SIGNUPS_DOMAINS_WHITELIST to non-existent domains to prevent unauthorised account creation.
Would you be open to modifying the logic so SIGNUPS_ALLOWED=false strictly prevents new account creation across all authentication schemes or by adding a new setting to prevent SSO automatic signups in the SSO regime?
<!-- gh-comment-id:4560968232 -->
@berglh commented on GitHub (May 28, 2026):
Hi @Timshel and @BlackDex,
I wanted to follow up on the behaviour of SIGNUPS_ALLOWED=false specifically when paired with an SSO_ONLY configuration using a public Identity Provider (like Google OIDC).
The current architecture presents a security ambiguity for self-hosters who want to leverage a public IdP strictly for identity verification (pre-authentication). If a service is exposed to the public internet with SSO_ONLY=true, a malicious actor with a standard @gmail.com address can authenticate against Google, and Vaultwarden will automatically provision them a new account, completely bypassing SIGNUPS_ALLOWED=false.
While managing authorised user lists is easily handled upstream in self-hosted IdPs (like Authelia or Authentik), it is not natively possible when using standard Google OIDC (Non-Google Workspace) for a small family setup. This forces users into the non-obvious workaround of setting a non-existent domain in SIGNUPS_DOMAINS_WHITELIST just to stop automatic provisioning, which I found by digging around in the GitHub issues.
This behaviour of using SSO_ONLY and the functionality of SIGNUPS_ALLOWED being ignored was not not explained in the [Envionrment Templates](https://github.com/dani-garcia/vaultwarden/blob/main/.env.template) I predominantly used when configuring Vaultwarden in K3S. I interpreted this as SIGNUPS_ALLOWED=false being explicit, like a lock-down for the entire Vaultwarden server.
To tighten this up and make the behaviour less ambiguous, I would like to propose the following options:
1. Enforce SIGNUPS_ALLOWED=false globally: Ideally, if sign-ups are disabled, an OIDC login should only succeed if the corresponding email already exists in the Vaultwarden database, regardless of successful IdP authentication. If it is the case that enabling this behaviour impacts IdP managed user access patterns when set to true (i.e. by exposing a basic non SSO sign-up pathway), then I can understand why this logic is in situ even if it's not explained clearly.
2. Introduce an explicit toggle: If the current behaviour is required for backward compatibility or managed IdP setups, we could introduce something like SSO_AUTO_SIGNUPS_ALLOWED=true/false (defaulting to true). This explicitly decouples OIDC provisioning from the standard sign-up flow, and would provide a mechanism for completely disabling sign-up with authorisation based only on the existing database members when using simple OIDC providers.
3. Documentation: At a minimum, if this behaviour is working as intended, the documentation should explicitly state that SIGNUPS_ALLOWED=false is ignored under SSO/OIDC configurations and in SSO_ONLY regimes, and that users utilising public IdPs must leverage SIGNUPS_DOMAINS_WHITELIST to non-existent domains to prevent unauthorised account creation.
Would you be open to modifying the logic so SIGNUPS_ALLOWED=false strictly prevents new account creation across all authentication schemes or by adding a new setting to prevent SSO automatic signups in the SSO regime?
Can you clarify what's the use case for an Identity provider where you do not control the user list with the current Vaultwarden ?
<!-- gh-comment-id:4561358553 -->
@Timshel commented on GitHub (May 28, 2026):
Hey,
Can you clarify what's the use case for an Identity provider where you do not control the user list with the current Vaultwarden ?
To clarify my objective, this is entirely about security hardening by leveraging a trusted Identity Provider (IdP). I use Google OIDC because it provides a high-assurance identity verification layer before a user even gets the chance to input a vault master password. I am trusting that the email attribute returned by Google is cryptographically verified and will map directly to an existing valid Vaultwarden user.
I am aware of the operational risk this introduces, such as if Google or the internet goes down, I may be locked out of write access for my vault. For my risk model, this is an acceptable trade-off for the added security of an external identity "firewall".
Regarding enforcement, one might suggest handling this upstream at the reverse proxy layer. For example, as I am using Traefik, it has OIDC middleware that I use and it can validate identities and handle user authorisation before passing traffic to a back-end. However, while that works perfectly for standard web apps, it tends to break multi-access ecosystem applications like Vaultwarden. Mobile applications and browser extensions typically do not handle upstream proxy OIDC challenge redirects gracefully, I have not tested if that is the case here.
Because multi-client applications require direct access to the API endpoints, the responsibility for authorising which authenticated identities are allowed into the application must ultimately fall on the Service Provider (Vaultwarden) itself. While the true authentication is technically handled by the combination of the user ID and the vault password, OIDC adds an additional layer of authentication beyond basic credentials. i.e. I need to have my MFA Google login first before I can even attempt to login with my vault password.
This brings me back to the core issue: when SSO_ONLY=true, we need a native, clean way to say, "Authenticate via the IdP, but if the identity isn't already in the local database, do not provision a new account." Relying on a dummy domain in SIGNUPS_DOMAINS_WHITELIST certainly works as a hack, but then if the domain in the future is in-fact valid and a user creates a Google account with that domain, then once again they would satisfy the requirements for provisioning an account in Vaultwarden. While my data inside Vaultwarden remains safe and encrypted, it does increase surface attack area of the web application by having a logged in user along with the issue of the resources unwanted guests would be consuming.
<!-- gh-comment-id:4561503927 -->
@berglh commented on GitHub (May 28, 2026):
@Timshel Thanks for the response.
To clarify my objective, this is entirely about security hardening by leveraging a trusted Identity Provider (IdP). I use Google OIDC because it provides a high-assurance identity verification layer before a user even gets the chance to input a vault master password. I am trusting that the email attribute returned by Google is cryptographically verified and will map directly to an existing valid Vaultwarden user.
I am aware of the operational risk this introduces, such as if Google or the internet goes down, I may be locked out of write access for my vault. For my risk model, this is an acceptable trade-off for the added security of an external identity "firewall".
Regarding enforcement, one might suggest handling this upstream at the reverse proxy layer. For example, as I am using Traefik, it has OIDC middleware that I use and it can validate identities and handle user authorisation before passing traffic to a back-end. However, while that works perfectly for standard web apps, it tends to break multi-access ecosystem applications like Vaultwarden. Mobile applications and browser extensions typically do not handle upstream proxy OIDC challenge redirects gracefully, I have not tested if that is the case here.
Because multi-client applications require direct access to the API endpoints, the responsibility for authorising which authenticated identities are allowed into the application must ultimately fall on the Service Provider (Vaultwarden) itself. While the true authentication is technically handled by the combination of the user ID and the vault password, OIDC adds an additional layer of authentication beyond basic credentials. i.e. I need to have my MFA Google login first before I can even attempt to login with my vault password.
This brings me back to the core issue: when SSO_ONLY=true, we need a native, clean way to say, "Authenticate via the IdP, but if the identity isn't already in the local database, do not provision a new account." Relying on a dummy domain in SIGNUPS_DOMAINS_WHITELIST certainly works as a hack, but then if the domain in the future is in-fact valid and a user creates a Google account with that domain, then once again they would satisfy the requirements for provisioning an account in Vaultwarden. While my data inside Vaultwarden remains safe and encrypted, it does increase surface attack area of the web application by having a logged in user along with the issue of the resources unwanted guests would be consuming.
For security with Google I would probably look to manage the app audience, but it seems to require an Organization (testing appears to have too many restrictions) and other public providers might not have any configuration.
As for implementation, I believe having separate rule for MP/SSO signup is an essential feature for those self-hosting a provider or using one they can configure.
As such I think it would make sense to use separate config like
SIGNUPS_ALLOWED to only restrict the account creation flow
SSO_SIGNUPS_ALLOWED to control SSO account creation (default to true)
While renaming SIGNUPS_ALLOWED could limit ambiguity I don't think it's worth it since the majority of setup are not using SSO.
<!-- gh-comment-id:4561982136 -->
@Timshel commented on GitHub (May 28, 2026):
Hum,
I can understand the MFA angle and I expect with trusted device (https://github.com/dani-garcia/vaultwarden/pull/7034) more people will be interested in this kind of setup.
For security with Google I would probably look to [manage the app audience](https://support.google.com/cloud/answer/15549945#zippy=), but it seems to require an Organization (testing appears to have too many restrictions) and other public providers might not have any configuration.
As for implementation, I believe having separate rule for MP/SSO signup is an essential feature for those self-hosting a provider or using one they can configure.
As such I think it would make sense to use separate config like
- `SIGNUPS_ALLOWED` to only restrict the account creation flow
- `SSO_SIGNUPS_ALLOWED` to control SSO account creation (default to `true`)
While renaming `SIGNUPS_ALLOWED` could limit ambiguity I don't think it's worth it since the majority of setup are not using SSO.
For what it's worth, I value having a master vault password that is completely separate from my OIDC provider for this specific use case. While I understand it can be viewed as a menace, when you're talking about the protection of your most valuable secrets, I see the the vault password as a strength that would only be weakened if it were to be able to be bypassed by trusted devices.
Certainly, trusted devices could add another layer of security in combination with the vault password, which is how I would personally prefer to use it, unless of course I'm misconstruing the point of the OP. Honestly, typing my vault password once and using a quick unlock mechanism with reasonably fast idle locking seems to me to be a happy compromise between security and functionality. Edit: In hindsight, if you're talking about accepting a challenge on your phone that requires an unlock via biometrics, and cannot just be accepted via notification or directly on your smart watch, then I guess this is not so bad having equivalence to the Android and iOS apps.
With respect to the Google OIDC client app configuration, as far as I understood it in the non-organisation configuration (i.e. free tier mode) where the Google Cloud Platform account does not have a subscription to Google Workspaces or paid GCP organisation, only when the client app is in testing mode are you able to limit the audience on the Google OIDC side.
As soon as you you publish a client app, which is not strictly necessary, but in order to have client app branding and to avoid other annoyances, it is required. Once published, it seems you are then not able to restrict the audience of the client app as you would with a paid organisation.
It's likely that most people who utilise this method of Google OIDC in the free-tier of GCP would stop at configuring the client app in testing mode, as there are some significant technical hurdles to jump to have the client app published. Namely in the proof of domain ownership via authoritative public DNS TXT record, and the public hosting of an app privacy policy page with specific structural constraints, which is likely non-trivial for the average Docker home-lab setup.
As such I think it would make sense to use separate config like
SIGNUPS_ALLOWED to only restrict the account creation flow
SSO_SIGNUPS_ALLOWED to control SSO account creation (default to true)
While renaming SIGNUPS_ALLOWED could limit ambiguity I don't think it's worth it since the majority of setup are not using SSO.
Agreed, this seem like the lowest risk security improvement. Particularly when you consider the existing user base, who are already familiar with the current operation, there is a greater risk of causing unexpected behaviour to modify the SIGNUPS_ALLOWED configuration key. Specifically for those in the basic authentication regime who don't read the release notes and simply reference the latest docker image.
Nevertheless, it would be probably be worthwhile disambiguating the use of the SIGNUPS_ALLOWED setting authentication scope through documentation with respect to its function in the SSO/OIDC regime, particularly in:
Is there anything you would like me to do for us to either reopen this issue or for me to submit a new feature request so that it can be adequately tracked?
<!-- gh-comment-id:4562559658 -->
@berglh commented on GitHub (May 28, 2026):
@Timshel
For what it's worth, I value having a master vault password that is completely separate from my OIDC provider for this specific use case. While I understand it can be viewed as a menace, when you're talking about the protection of your most valuable secrets, I see the the vault password as a strength that would only be weakened if it were to be able to be bypassed by trusted devices.
Certainly, trusted devices could add another layer of security in combination with the vault password, which is how I would personally prefer to use it, unless of course I'm misconstruing the point of the OP. Honestly, typing my vault password once and using a quick unlock mechanism with reasonably fast idle locking seems to me to be a happy compromise between security and functionality. **Edit**: In hindsight, if you're talking about accepting a challenge on your phone that requires an unlock via biometrics, and cannot just be accepted via notification or directly on your smart watch, then I guess this is not so bad having equivalence to the Android and iOS apps.
With respect to the Google OIDC client app configuration, as far as I understood it in the non-organisation configuration (i.e. free tier mode) where the Google Cloud Platform account does not have a subscription to Google Workspaces or paid GCP organisation, only when the client app is in `testing` mode are you able to limit the audience on the Google OIDC side.
As soon as you you `publish` a client app, which is not strictly necessary, but in order to have client app branding and to avoid other annoyances, it is required. Once published, it seems you are then not able to restrict the audience of the client app as you would with a paid organisation.
It's likely that most people who utilise this method of Google OIDC in the free-tier of GCP would stop at configuring the client app in `testing` mode, as there are some significant technical hurdles to jump to have the client app `published`. Namely in the proof of domain ownership via authoritative public DNS TXT record, and the public hosting of an app privacy policy page with specific structural constraints, which is likely non-trivial for the average Docker home-lab setup.
> As such I think it would make sense to use separate config like
>
> * `SIGNUPS_ALLOWED` to only restrict the account creation flow
> * `SSO_SIGNUPS_ALLOWED` to control SSO account creation (default to `true`)
>
> While renaming `SIGNUPS_ALLOWED` could limit ambiguity I don't think it's worth it since the majority of setup are not using SSO.
Agreed, this seem like the lowest risk security improvement. Particularly when you consider the existing user base, who are already familiar with the current operation, there is a greater risk of causing unexpected behaviour to modify the `SIGNUPS_ALLOWED` configuration key. Specifically for those in the basic authentication regime who don't read the release notes and simply reference the `latest` docker image.
Nevertheless, it would be probably be worthwhile disambiguating the use of the `SIGNUPS_ALLOWED` setting authentication scope through documentation with respect to its function in the SSO/OIDC regime, particularly in:
- https://github.com/dani-garcia/vaultwarden/blob/main/.env.template
- https://github.com/dani-garcia/vaultwarden/wiki/Enabling-SSO-support-using-OpenId-Connect
- https://github.com/dani-garcia/vaultwarden/wiki/Disable-registration-of-new-users
- https://github.com/dani-garcia/vaultwarden/wiki/Using-Docker-Compose
Possibly mentioning the actions of the new setting if implemented here:
- https://github.com/dani-garcia/vaultwarden/wiki/Disable-invitations
Is there anything you would like me to do for us to either reopen this issue or for me to submit a new feature request so that it can be adequately tracked?
Should be simple enough I'll add it to my fork then open a PR and let the maintainers decide :)
<!-- gh-comment-id:4563331669 -->
@Timshel commented on GitHub (May 28, 2026):
Should be simple enough I'll add it to my fork then open a PR and let the maintainers decide :)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @capsel22 on GitHub (Apr 2, 2026).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/7050
Prerequisites
Vaultwarden Support String
Your environment (Generated via diagnostics page)
Config & Details (Generated via diagnostics page)
Show Config & Details
Environment settings which are overridden: DOMAIN, ADMIN_TOKEN
Config:
Vaultwarden Build Version
1.35.4
Deployment method
Official Container Image
Custom deployment method
No response
Reverse Proxy
Nginx Proxy Manager v2.13.6
Host/Server Operating System
Linux
Operating System Version
No response
Clients
Web Vault
Client Version
No response
Steps To Reproduce
Expected Result
with the "signups_allowed": false AND user not created/invited I was expecting an error and inability to sign up/create user
Actual Result
User can sign up and create an account.
Tested on 3 different users which weren't invited nor previously had an account
Logs
Screenshots or Videos
Additional Context
No response
@BlackDex commented on GitHub (Apr 2, 2026):
If I'm correct SSO bypasses that check. But not sure from the top of my head. @Timshel maybe knows this better?
@Timshel commented on GitHub (Apr 2, 2026):
Yes the idea is to remove the need to invite users one by one for the configured provider.
The
signups_domains_whitelistis still applied butsignups_allowedis ignored.It's not really intended to use with providers where you do not control the user list, it becomes kind of useless since the main feature are to remove the need for invitation and allow access revocation at the provider level if
sso_onlyis used.@capsel22 commented on GitHub (Apr 2, 2026):
Alright I see.
Not ideal, I hoped to use the Google OAuth same as I use for other self-hosted apps but they do allow control of limiting user creation to only invited or created only.
I think in this scenario I will disable it. Maybe it will be considered as a feature in the future.
@capsel22 commented on GitHub (Apr 2, 2026):
Thanks both for your quick replies. All the best
@Timshel commented on GitHub (Apr 2, 2026):
Maybe I'm missing something but if you still want to invite users I don't understand what OAuth is bringing you ?
It does open the possibility of not sending/storing the master password to/in the server but at the moment this is not supported.
It might become possible some day since Bitwarden is adding features removing the need for master password (Ex: trusted devices) but I don't know how it interacts with the part of the application/server which used to require it (Ex: adding a 2FA device).
@capsel22 commented on GitHub (Apr 2, 2026):
Ohhh yeah, I didn't realise you can't hide the master password requirement when using sso.
You are right at this point in time there is no benefit.
@berglh commented on GitHub (May 28, 2026):
Hi @Timshel and @BlackDex,
I wanted to follow up on the behaviour of SIGNUPS_ALLOWED=false specifically when paired with an SSO_ONLY configuration using a public Identity Provider (like Google OIDC).
The current architecture presents a security ambiguity for self-hosters who want to leverage a public IdP strictly for identity verification (pre-authentication). If a service is exposed to the public internet with SSO_ONLY=true, a malicious actor with a standard @gmail.com address can authenticate against Google, and Vaultwarden will automatically provision them a new account, completely bypassing SIGNUPS_ALLOWED=false.
While managing authorised user lists is easily handled upstream in self-hosted IdPs (like Authelia or Authentik), it is not natively possible when using standard Google OIDC (Non-Google Workspace) for a small family setup. This forces users into the non-obvious workaround of setting a non-existent domain in SIGNUPS_DOMAINS_WHITELIST just to stop automatic provisioning, which I found by digging around in the GitHub issues.
This behaviour of using SSO_ONLY and the functionality of SIGNUPS_ALLOWED being ignored was not not explained in the Envionrment Templates I predominantly used when configuring Vaultwarden in K3S. I interpreted this as SIGNUPS_ALLOWED=false being explicit, like a lock-down for the entire Vaultwarden server.
To tighten this up and make the behaviour less ambiguous, I would like to propose the following options:
Enforce SIGNUPS_ALLOWED=false globally: Ideally, if sign-ups are disabled, an OIDC login should only succeed if the corresponding email already exists in the Vaultwarden database, regardless of successful IdP authentication. If it is the case that enabling this behaviour impacts IdP managed user access patterns when set to true (i.e. by exposing a basic non SSO sign-up pathway), then I can understand why this logic is in situ even if it's not explained clearly.
Introduce an explicit toggle: If the current behaviour is required for backward compatibility or managed IdP setups, we could introduce something like SSO_AUTO_SIGNUPS_ALLOWED=true/false (defaulting to true). This explicitly decouples OIDC provisioning from the standard sign-up flow, and would provide a mechanism for completely disabling sign-up with authorisation based only on the existing database members when using simple OIDC providers.
Documentation: At a minimum, if this behaviour is working as intended, the documentation should explicitly state that SIGNUPS_ALLOWED=false is ignored under SSO/OIDC configurations and in SSO_ONLY regimes, and that users utilising public IdPs must leverage SIGNUPS_DOMAINS_WHITELIST to non-existent domains to prevent unauthorised account creation.
Would you be open to modifying the logic so SIGNUPS_ALLOWED=false strictly prevents new account creation across all authentication schemes or by adding a new setting to prevent SSO automatic signups in the SSO regime?
@Timshel commented on GitHub (May 28, 2026):
Hey,
Can you clarify what's the use case for an Identity provider where you do not control the user list with the current Vaultwarden ?
@berglh commented on GitHub (May 28, 2026):
@Timshel Thanks for the response.
To clarify my objective, this is entirely about security hardening by leveraging a trusted Identity Provider (IdP). I use Google OIDC because it provides a high-assurance identity verification layer before a user even gets the chance to input a vault master password. I am trusting that the email attribute returned by Google is cryptographically verified and will map directly to an existing valid Vaultwarden user.
I am aware of the operational risk this introduces, such as if Google or the internet goes down, I may be locked out of write access for my vault. For my risk model, this is an acceptable trade-off for the added security of an external identity "firewall".
Regarding enforcement, one might suggest handling this upstream at the reverse proxy layer. For example, as I am using Traefik, it has OIDC middleware that I use and it can validate identities and handle user authorisation before passing traffic to a back-end. However, while that works perfectly for standard web apps, it tends to break multi-access ecosystem applications like Vaultwarden. Mobile applications and browser extensions typically do not handle upstream proxy OIDC challenge redirects gracefully, I have not tested if that is the case here.
Because multi-client applications require direct access to the API endpoints, the responsibility for authorising which authenticated identities are allowed into the application must ultimately fall on the Service Provider (Vaultwarden) itself. While the true authentication is technically handled by the combination of the user ID and the vault password, OIDC adds an additional layer of authentication beyond basic credentials. i.e. I need to have my MFA Google login first before I can even attempt to login with my vault password.
This brings me back to the core issue: when SSO_ONLY=true, we need a native, clean way to say, "Authenticate via the IdP, but if the identity isn't already in the local database, do not provision a new account." Relying on a dummy domain in SIGNUPS_DOMAINS_WHITELIST certainly works as a hack, but then if the domain in the future is in-fact valid and a user creates a Google account with that domain, then once again they would satisfy the requirements for provisioning an account in Vaultwarden. While my data inside Vaultwarden remains safe and encrypted, it does increase surface attack area of the web application by having a logged in user along with the issue of the resources unwanted guests would be consuming.
@Timshel commented on GitHub (May 28, 2026):
Hum,
I can understand the MFA angle and I expect with trusted device (https://github.com/dani-garcia/vaultwarden/pull/7034) more people will be interested in this kind of setup.
For security with Google I would probably look to manage the app audience, but it seems to require an Organization (testing appears to have too many restrictions) and other public providers might not have any configuration.
As for implementation, I believe having separate rule for MP/SSO signup is an essential feature for those self-hosting a provider or using one they can configure.
As such I think it would make sense to use separate config like
SIGNUPS_ALLOWEDto only restrict the account creation flowSSO_SIGNUPS_ALLOWEDto control SSO account creation (default totrue)While renaming
SIGNUPS_ALLOWEDcould limit ambiguity I don't think it's worth it since the majority of setup are not using SSO.@berglh commented on GitHub (May 28, 2026):
@Timshel
For what it's worth, I value having a master vault password that is completely separate from my OIDC provider for this specific use case. While I understand it can be viewed as a menace, when you're talking about the protection of your most valuable secrets, I see the the vault password as a strength that would only be weakened if it were to be able to be bypassed by trusted devices.
Certainly, trusted devices could add another layer of security in combination with the vault password, which is how I would personally prefer to use it, unless of course I'm misconstruing the point of the OP. Honestly, typing my vault password once and using a quick unlock mechanism with reasonably fast idle locking seems to me to be a happy compromise between security and functionality. Edit: In hindsight, if you're talking about accepting a challenge on your phone that requires an unlock via biometrics, and cannot just be accepted via notification or directly on your smart watch, then I guess this is not so bad having equivalence to the Android and iOS apps.
With respect to the Google OIDC client app configuration, as far as I understood it in the non-organisation configuration (i.e. free tier mode) where the Google Cloud Platform account does not have a subscription to Google Workspaces or paid GCP organisation, only when the client app is in
testingmode are you able to limit the audience on the Google OIDC side.As soon as you you
publisha client app, which is not strictly necessary, but in order to have client app branding and to avoid other annoyances, it is required. Once published, it seems you are then not able to restrict the audience of the client app as you would with a paid organisation.It's likely that most people who utilise this method of Google OIDC in the free-tier of GCP would stop at configuring the client app in
testingmode, as there are some significant technical hurdles to jump to have the client apppublished. Namely in the proof of domain ownership via authoritative public DNS TXT record, and the public hosting of an app privacy policy page with specific structural constraints, which is likely non-trivial for the average Docker home-lab setup.Agreed, this seem like the lowest risk security improvement. Particularly when you consider the existing user base, who are already familiar with the current operation, there is a greater risk of causing unexpected behaviour to modify the
SIGNUPS_ALLOWEDconfiguration key. Specifically for those in the basic authentication regime who don't read the release notes and simply reference thelatestdocker image.Nevertheless, it would be probably be worthwhile disambiguating the use of the
SIGNUPS_ALLOWEDsetting authentication scope through documentation with respect to its function in the SSO/OIDC regime, particularly in:Possibly mentioning the actions of the new setting if implemented here:
Is there anything you would like me to do for us to either reopen this issue or for me to submit a new feature request so that it can be adequately tracked?
@Timshel commented on GitHub (May 28, 2026):
Should be simple enough I'll add it to my fork then open a PR and let the maintainers decide :)