SSO callback scheme handler


I’m using Bitwarden for a while now with the browser extension (Firefox) as well as the desktop app (AppImage) on Linux. (openSUSE Tumbleweed)

A few month ago I set up the app on my laptop against our company Bitwarden account connected via SSO (private instance) which worked fine.
Now since the app now supports multiple accounts I tried to set up another machine but I’m totally failing the SSO auth step now.
Clicking on SSO login opens the correct Bitwarden page on the private server and I can SSO login as well but then I’m ending up on https://bitwarden.$
w/o anything else happening.

Trying to track down what is wrong I guess that the SSO callback is supposed to reach the app via the bitwarden:// scheme which apparently is failing.
If that’s the issue then I’m wondering why this is failing now and worked a few month ago. Or what I can check on my system to find out why the bitwarden scheme is not registered.

Any ideas?


I cannot even log in to Bitwarden. So not sure which URI match settings you mean. I only know the ones from the browser plugin to prefill login forms.

Sorry, ignore that. It’s not relevant. Maybe there was an update in the meanwhile? Your URL scheme differs a little.

Of course, you might have configured it that way, like in the next question.

My next guess would to make sure the instance can reach your identity provider. Final idea is that you haven’t enabled automatic user management (you’d have to manually configure each user otherwise). This would have the effect of requiring master password.

Let me clarify more. Most of my colleagues are using the browser plugin or different desktop systems (primarily Mac) and have no issues at all with our system.
So I have to assume it’s the Bitwarden AppImage which does not work as it should.

Let me ask a couple questions because I think I made some faulty assumptions.

You are admin of this system? This company account with old method, you just authenticated your identity to it–the vault was already decrypted? Does your personal account authenticate to the Identity Provider alright?

I’m not admin of the system. I’m a user trying to set the AppImage Bitwarden app against that system which fails.
I don’t know anything about an “old method” but I’m happy to contact my admins.
I have a fully working account on that company bitwarden server which I can use via web w/o issues. And yes, the SSO is our company SSO which I’m working with the whole day.

I’m still convinced that it’s “just” the callback from browser to the desktop app which apparently is supposed to happen via this redirect in the flow:
location: bitwarden://sso-callback?code=&scope=api%20offline_access&state=%3D
But this does apparently not arrive in the app.

1 Like

Alright, found an issue on Github. Looks really familiar, let me know.

I don’t think you’re doing anything wrong, apparently the app image has dependancy issues on certain distros of Linux. No teliing when a fix is due, because these issues are not new. Only real thing to do is to get in contact with maintainers.

Somebody said this workaround, well works. Basically, it forces the app to run with that callback.

That workaround does not work for me.
Using Firefox as standard browser and when the SSO flow is triggered there is no browser feedback at all. So I cannot tell anyone to use the AppImage for bitwarden.

But meanwhile I have found additional things and was finally able to make it work:
It seems the AppImage integration into Linux relies on $something which does the app registration into the system. On openSUSE that seems to be appimaged which creates the desktop file containing the x-scheme-handler.
To register it actually the following command is required manually it seems:
$ update-desktop-database $HOME/.local/share/applications

Afterwards the scheme handler is registered and bitwarden is called BUT still does not work.
I think this is the case because the desktop file contains an Exec definition not including %u so it does not call the app with the callback URI.
When I check the contents of the AppImage it contains:
Exec=AppRun --no-sandbox %U

Therefore again I think that appimaged on openSUSE is not correctly creating the desktop file based on that.

I hope my analysis is correct and in that case both issues are happening because appimaged is not doing the right thing with AppImage integration on openSUSE. So will try to see if improvements can be done there.

1 Like