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.
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.