Organization invitation forces SSO login when orgSsoIdentifier is present – no way to choose login method

[proofofcopilot]

Describe the bug / question

I am running a Vaultwarden (1.35.2) instance that supports both:

• SSO login
• Basic login (email + master password)

When inviting a new user to an organization, Vaultwarden generates an invitation link like the following:

https://vaultwarden.example.com/#/accept-organization/
?email=max.mustermann%40example.com
&organizationName=Example+Org
&organizationId=ce9eec73-67df-4eda-a9cd-abbbbe9c2641
&organizationUserId=a72508e6-e3a9-42c4-a68e-7227664f7850
&token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
&orgUserHasExistingUser=false
&orgSsoIdentifier=ce9eec73-67df-4eda-a9cd-abbbbe9c2641

Because orgSsoIdentifier is present, the invited user is forced to use SSO during the acceptance flow.

If I remove orgSsoIdentifier from the URL, the same user can log in using basic authentication (email + master password) without issues.

Steps to reproduce

1. Configure Vaultwarden with:

• Organization SSO enabled
• Basic login (email + master password) also enabled

2. Invite a new user to an organization
3. User receives the invitation link containing orgSsoIdentifier
4. Open the link as a new user (no existing account)

Actual behavior

• The invitation flow enforces SSO login
• The user cannot choose basic login
• Removing orgSsoIdentifierfrom the URL allows basic login

Expected behavior / question

Is there a supported way to define which authentication methods an invited user may use before sending the invitation?

For example:

• Allow the user to choose between SSO and basic login
• Force basic login for certain invitations
• Control this behavior via organization or invitation settings

Currently, it appears that the presence of orgSsoIdentifier alone determines the login method, without any admin-side configuration.

Additional context

This affects onboarding when organizations want to:

• Use SSO for existing users
• Still allow basic login for certain invited users (e.g. external users)

Manually modifying the invitation URL is not a viable solution, right?

Thanks for any clarification or guidance on the intended behavior here.

[stefan0xC]

I think this has ben fixed by #6824

[proofofcopilot]

correct fixed in #6824