add SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION

.env.template

@@ -445,6 +445,8 @@
 # SSO_ONLY=false
 ## On SSO Signup if a user with a matching email already exists make the association
 # SSO_SIGNUPS_MATCH_EMAIL=true
+## Allow unknown email verification status. Allowing this with `SSO_SIGNUPS_MATCH_EMAIL=true` open potential account takeover.
+# SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false
 ## Base URL of the OIDC server (auto-discovery is used)
 ##  - Should not include the `/.well-known/openid-configuration` part and no trailing `/`
 ##  - ${SSO_AUTHORITY}/.well-known/openid-configuration should return a json document: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationResponse

SSO.md

@@ -15,6 +15,7 @@ The following configurations are available
  - `SSO_ENABLED` : Activate the SSO
  - `SSO_ONLY` : disable email+Master password authentication
  - `SSO_SIGNUPS_MATCH_EMAIL`: On SSO Signup if a user with a matching email already exists make the association (default `true`)
+ - `SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION`: Allow unknown email verification status (default `false`). Allowing this with `SSO_SIGNUPS_MATCH_EMAIL` open potential account takeover.
  - `SSO_AUTHORITY` : the OpenID Connect Discovery endpoint of your SSO
  	- Should not include the `/.well-known/openid-configuration` part and no trailing `/`
  	- $SSO_AUTHORITY/.well-known/openid-configuration should return the a json document: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationResponse
@@ -57,6 +58,16 @@ To delete the association (this has no impact on the `Vaultwarden` user):
 TRUNCATE TABLE sso_users;
 ```
 
+### On `SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION`
+
+If your provider does not send the verification status of emails you will need to activate this setting.
+
+If set with `SSO_SIGNUPS_MATCH_EMAIL=true` (the default), then an user can associate with an existing non sso account even if he does not control the email.
+This allow an user to gain access to sensitive information but the Master password is still required to read the passwords.
+
+As such when using `SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION` it is recommended to disable `SSO_SIGNUPS_MATCH_EMAIL`.
+If you need to associate non sso users try to keep both settings activated for the shortest time possible.
+
 ## Client Cache
 
 By default the client cache is disabled since it can cause issues with the signing keys.

src/api/identity.rs

@@ -202,8 +202,13 @@ async fn _sso_login(data: ConnectData, user_uuid: &mut Option<String>, conn: &mu
                 err!("Email domain not allowed");
             }
 
-            if !user_infos.email_verified.unwrap_or(true) {
-                err!("Email needs to be verified before you can use VaultWarden");
+            match user_infos.email_verified {
+                None if !CONFIG.sso_allow_unknown_email_verification() => err!(
+                    "Your provider does not send email verification status.\n\
+                    You will need to change the server configuration (check `SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION`) to log in."
+                ),
+                Some(false) => err!("You need to verify your email with your provider before you can log in"),
+                _ => (),
             }
 
             let mut user = User::new(user_infos.email, user_infos.user_name);

src/config.rs

@@ -643,6 +643,8 @@ make_config! {
         sso_only:                       bool,   true,   def,    false;
         /// Allow email associtation |> Associate existing non-sso user based on email
         sso_signups_match_email:        bool,   true,   def,    true;
+        /// Allow unknown email verification status |> Allowing this with `SSO_SIGNUPS_MATCH_EMAIL=true` open potential account takeover.
+        sso_allow_unknown_email_verification: bool, false, def, false;
         /// Client ID
         sso_client_id:                  String, false,   def,    String::new();
         /// Client Key