mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-04-26 01:35:54 +03:00
[GH-ISSUE #6613] OIDC (Authentik) Login Option Des Not Appear on Desktop Browser Web Page #2486
Labels
No labels
SSO
Third party
better for forum
bug
bug
documentation
duplicate
enhancement
future Vault
future Vault
future Vault
good first issue
help wanted
low priority
notes
pull-request
question
troubleshooting
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/vaultwarden#2486
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @pr0927 on GitHub (Dec 28, 2025).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/6613
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, SIGNUPS_ALLOWED, ADMIN_TOKEN
Config:
Vaultwarden Build Version
1.35
Deployment method
Official Container Image
Custom deployment method
No response
Reverse Proxy
Nginx Proxy Manager
Host/Server Operating System
Linux
Operating System Version
Debian
Clients
Web Vault
Client Version
No response
Steps To Reproduce
Expected Result
I expected to see an OIDC login option.
Actual Result
I don't see an OIDC login option - I do on mobile, and I do within the Firefox browser extension - but not in any desktop web browser.
Logs
Screenshots or Videos
Additional Context
Apologies in advance for the poor practice of putting some of this info in environment variables (was one of my first Docker containers, some legacy security practices...), planning on fixing this shortly with a .env file, but for now, my Docker compose:
@dani-garcia commented on GitHub (Dec 28, 2025):
If you see the option within other clients, it's likely your web browser has some old configuration cached. Can you try opening the web vault in private mode? That should make sure that some stale config is not messing things for you
@pr0927 commented on GitHub (Dec 28, 2025):
Whoa what was a quick response - I did try it in Firefox, and I tried in Chromium too (also in a private window) - same deal.
Could NPM be playing a role?
@dani-garcia commented on GitHub (Dec 28, 2025):
Hmm weird, I wonder if you bypass the button and go directly to the SSO login page, does it work?
If that works, then as far as I know we're hiding the button with CSS, so you can check if the CSS is being generated correctly:
If you see a
vw-sso-loginclass in that css then something is going funky there.@pr0927 commented on GitHub (Dec 28, 2025):
Interesting, I get this when I visit that URL:
My CSS:
@csickendieck commented on GitHub (Dec 28, 2025):
I just updated it, following authentic's instructions based on the Vaultwarden Wiki.
It's the same for me. Also in Edge and Opera.
CSS class:
.providers-2fa-3,.providers-2fa-1,app-user-layout app-danger-zone button:nth-child(1),bit-nav-logo bit-nav-item .bwi-shield,bit-dialog div.tw-ml-4:has(bit-form-control input),bit-dialog div.tw-col-span-4:has(input[formcontrolname*=access],input[formcontrolname*=manage]),app-security>app-two-factor-setup>form,app-org-reports-home>app-report-list>div.tw-inline-grid>div:nth-child(6),app-org-account form.ng-untouched:nth-child(5),app-organization-plans>form>bit-section:nth-child(2),bit-nav-item[route="settings/two-factor"],a[href$="/settings/two-factor"],.vw-other-login,.vw-or-text,.vw-passkey-login,app-user-layout app-password-settings app-webauthn-login-settings,.vw-sso-login,.vw-email-sso,a[href$="/settings/sponsored-families"],bit-nav-item[route="settings/subscription"],.vw-hide,head{display:none !important}bit-nav-logo bit-nav-item a:before{content:"";background-image:url("../images/icon-white.svg");background-repeat:no-repeat;background-position:center center;height:32px;display:block}Bypassing the login page:
@csickendieck commented on GitHub (Dec 28, 2025):
@pr0927 Could you please check your admin page and the OpenID Connect SSO settings?
Is it enabled? It wasn't enabled for me, so I enabled it, even though the environment variables were correct in the first step.
This resolved the local IP address issue. However, I'm still getting a redirect error. So what, authentic is configured for the domain.
Local IP address: Seems to be working.
Domain: SSO still isn't working (see screenshots above). I'm also using the Nginx Proxy Manager.
@m-spitfire commented on GitHub (Dec 28, 2025):
I have the same issue with @pr0927 where I can see SSO option in other clients, and it works, however the web client doesn't show the button. The sso link also works - where I get the page and after entering my email I login. I think it's a css issue
The page doesn't show the button, even though it's in the html. The reason is they are under a div with class
tw-hidden.@ljhardy commented on GitHub (Dec 28, 2025):
Slightly different problem, maybe related, this is my initial login screen, even though I have SSO_ONLY: set to false:
When I fill in the email address and hit "Use single sign-in", it directs me to my SSO (Authentik), then back to vaultwarden for my Authenticator code, then right back to the initial login screen, above.
@radokristof commented on GitHub (Dec 28, 2025):
I had the same issue. I was using Cloudflare proxy and it had some old assets configured, that's why private browsing, clearing cache, etc.. did not work.
Clearing Cloudflare cache for my domain worked and SSO button appeared.
@dani-garcia commented on GitHub (Dec 28, 2025):
Yeah, my guess is there's some proxy cache causing issues, if you open
https://vault.your.domain/css/vaultwarden.cssand see.vw-sso-loginin it, try openinghttps://vault.your.domain/css/vaultwarden.css?abc=123to try to bust the proxy and browser caches. If the result from that doesn't have the.vw-sso-loginclass in it, then your issue is with some caching layer somewhere. We're putting headers on that file to be cached for a day, so it might be causing issues:github.com/dani-garcia/vaultwarden@eb2a56aea1/src/api/web.rs (L102-L103)@pr0927 commented on GitHub (Dec 28, 2025):
Yep enabled in there. I never tried it with local IP, only my external domain address.
Oh! Going to give this a try then.
Yep changing to the "=123" URL made that bit disappear.
@ljhardy commented on GitHub (Dec 28, 2025):
In my case, after I changed the token lifetime to something longer that 5 minutes, I got farther along in the process. After clearing the cache etc. AND changing the token lifetime as indicated in the wiki, it seems to be working!!
@pr0927 commented on GitHub (Dec 28, 2025):
Alright clearing the Cloudflare cache like @radokristof suggested worked. But interestingly, I can't proceed on this page until I put my e-mail address in - when I click on "Use single sign-on" I get this:
Once I do put in my e-mail address and choose that, it proceeds to Authentik. That part worked fine and after I put my master password in, I got into my vault.
One thing to note - I saw this same page on mobile when re-logging into my Bitwarden Android app:
BUT, that empty box was filled with some "dummy" placeholder text - I submitted it and it worked. Should I even be seeing that page? If so, what should be put in there? Did the cache cleanse make it unlikely to see it again?
@csickendieck commented on GitHub (Dec 28, 2025):
The Cloudflare cache and the token lifetime, that was it in my case. Just clear the Cloudflare cache haven't worked.
Thank you so much @radokristof @dani-garcia @ljhardy @pr0927. You're great.
@buzzard10 commented on GitHub (Dec 29, 2025):
Is it really required to enter email address? It would be great if we could skip this part..
@austin-dudzik commented on GitHub (Dec 29, 2025):
Can also confirm that it is indeed Cloudflare's side, as I have the same setup using Authentik and CF Tunnels, and was not seeing the SSO button either after environment variable changes, leading me here.
It's as easy as going into the Cloudflare dashboard, navigating to the domain, then Caching -> Configuration -> Purge Cache -> Purge Everything.
@austin-dudzik commented on GitHub (Dec 29, 2025):
@buzzard10 Yes, I believe there wouldn't really be any way around not requiring the email address, as it appears the official Bitwarden web vault (vault.bitwarden.com) also behaves the same way when selecting single sign-on before entering an email address.
The change would need to come from Bitwarden's side.
@buzzard10 commented on GitHub (Dec 31, 2025):
I don't get it, what's the point of turning on the SSO, if you still have to enter your email address (which can be simply read from SSO response) & master password.
@h725rk commented on GitHub (Jan 1, 2026):
I have the same problem.
I deleted the cache of cloudflare and my browser. The Access token validity is on 10 Minutes, already when setting it up.
If I use the following link https://vw.mydomain.de/#/sso it will be redirected to my authentik and the login works. After the login in authentik it will be a redirect to vaultwarden and I have to use my MFA, after after I entered this, I go back to the normal page.
Here is my Docker Config for VW:
@h725rk commented on GitHub (Jan 1, 2026):
OK, after deleting the cache and all cookies, I got the SSO Page. But after login with authentik, VW needs a MFA and after this my vault is blocked and needs the master password.
Does I have to delete the MFA on VW and VW does not block the vault automatically?
@ljhardy commented on GitHub (Jan 1, 2026):
My understanding is that the master password is required to decrypt stuff on disk so it appears that for most the OIDC integration is of minimal value.
@h725rk commented on GitHub (Jan 1, 2026):
OK, than i will be ask every time after the vault is lock out.
Thats not a good solution.
@m-spitfire commented on GitHub (Jan 1, 2026):
I think this issue is resolved. I also just cleared the cache in cloudflare and everything now works fine.