Hello,
we have recently implemented Bitwarden in our company. So far everything is working fine. We have also enabled SSO so that our employees can log in to Bitwarden using their Azure AD corporate account. However, it has happened a few times now that employees want to log in from the Bitwarden website using the Log In button and this is where, if you use SSO, it starts to be a bit irritating. If you go from https://bitwarden.com/ to the Log in button, the login pages comes up and you have to enter your email. There is no Enterprise SSO button yet. If you go further, the master password is requested, but this is not valid, because the employee must first log in via SSO. This sequence is therefore somewhat illogical and very irritating for some people. This should be improved. Thanks
Thanks for the feedback, in the meantime, your team can also bookmark the following links: Login with SSO FAQs | Bitwarden Help Center
https://vault.bitwarden.com/#/sso?identifier=your-org-idfor cloud-hosted instanceshttps://your.domain.com/#/sso?identifier=your-org-idfor self-hosted instances
Awesome! The link with the org identifier is great! The only thing is, from my perspective, when the user gets the invitation via email, I don’t believe it does include the org identifier, thus what Hannes_Egger reports remain true.
I witnessed it twice yesterday with two colleagues whom happen to be very technically skilled (Programmers and DevOps) and even though, the habit we all have is to “Create a new account” rather than authenticate. Only after we choose authenticate does the the SSO come.
On the contrary, when the users chose “Create an account”, they proceed with the account creation then get this error message:
Error
There was an unexpected error during single sign-on.
User. '@, has already been invited to this organization 'XXX Accept the invite in order to log in with SSO
Request ID:
Perhaps, you can add a feature to either give us more control on the onboarding workflow via the invitation email OR streamline it to be more straightforward when an SSO user is invited. Provided the invitation is triggered when the user is sync’ed from AAD with the Directory Connector. There’s no confusion on the origin of the user, right?
I agree with making the Enterprise login much easier. If we invite users with an email address for our domain and have already connected SCIM and SSO with AzureAD, they shouldn’t need the SSO Identifier and the long loop of verification and confirmation etc. Cumbersome at best for technical users and will only discourage non-technical users for getting on board.
This post sums up a lot of the hurdles for onboarding. Improve Onboarding
Keep the two-steps of Authentication via Azure SSO and Decryption via Master Password, but let’s get rid of all the extra steps that make it hard for users to get started.
Any plan to schedule work here? Using SSO and presenting login options that simply don’t work is a bad UX – just configuring off (on the extension) the options would be a tiny change but markedly improve the flow / support pain.