WebAuthn FIDO2 connection problem with Chrome web plugin #1423

New Issue

OVERLORD · 2026-02-05T00:54:22+03:00

OVERLORD commented

2026-02-05 00:54:22 +03:00

Originally created by @Nyxtorm on GitHub (Dec 12, 2022).

Subject of the issue

WebAuthn FIDO2 connection problem with Chrome web plugin

Deployment environment

Your environment (Generated via diagnostics page)

Vaultwarden version: v1.26.0-b7c9a346
Web-vault version: v2022.11.1
Running within Docker: false (Base: Debian)
Environment settings overridden: false
Uses a reverse proxy: true
IP Header check: true (X-Real-IP)
Internet access: true
Internet access via a proxy: false
DNS Check: true
Time Check: true
Domain Configuration Check: true
HTTPS Check: true
Database type: SQLite
Database version: 3.39.2
Clients used: Windows / Android / Chrome / Web
Reverse proxy and version: Nginx 1.23.2

Other relevant details:

Chrome version: 108.0.5359.99
Chrome Plugin version: 2022.10.1
Windows 11 22H2 22621.900
Nginx reverse proxy 1.23.2 w/ Debian 11 6.0.3

Steps to reproduce

Connect to the vault with the Chrome plugin and WebAuthn FIDO2

Expected behaviour

There should be a notification to validate the WebAuthn FIDO2 key

Actual behaviour

An error when selecting dual authentication via WebAuthn FIDO 2 :

I am no longer an official Btwarden premium user and cannot validate that the problem only occurs with Vaultwarden.

The problem is apparently only present with the browser client, I have no problem authenticating via WebAuthn FIDO 2 via the Windows client, Android client or directly via the web vault.

Originally created by @Nyxtorm on GitHub (Dec 12, 2022). ### Subject of the issue WebAuthn FIDO2 connection problem with Chrome web plugin ### Deployment environment ### Your environment (Generated via diagnostics page) - Vaultwarden version: v1.26.0-b7c9a346 - Web-vault version: v2022.11.1 - Running within Docker: false (Base: Debian) - Environment settings overridden: false - Uses a reverse proxy: true - IP Header check: true (X-Real-IP) - Internet access: true - Internet access via a proxy: false - DNS Check: true - Time Check: true - Domain Configuration Check: true - HTTPS Check: true - Database type: SQLite - Database version: 3.39.2 - Clients used: Windows / Android / Chrome / Web - Reverse proxy and version: Nginx 1.23.2 Other relevant details: - Chrome version: 108.0.5359.99 - Chrome Plugin version: 2022.10.1 - Windows 11 22H2 22621.900 - Nginx reverse proxy 1.23.2 w/ Debian 11 6.0.3 ### Steps to reproduce 1. Connect to the vault with the Chrome plugin and WebAuthn FIDO2 ### Expected behaviour There should be a notification to validate the WebAuthn FIDO2 key ### Actual behaviour An error when selecting dual authentication via WebAuthn FIDO 2 : <img src="https://i.imgur.com/cZhBZbw.png" width=30% height=30%> I am no longer an official Btwarden premium user and cannot validate that the problem only occurs with Vaultwarden. The problem is apparently only present with the browser client, I have no problem authenticating via WebAuthn FIDO 2 via the Windows client, Android client or directly via the web vault.

OVERLORD closed this issue

2026-02-05 00:54:25 +03:00

OVERLORD commented

2026-02-05 00:54:29 +03:00

@tessus commented on GitHub (Dec 12, 2022):

~~Bitwarden deactivated passwordless login in 2022.11.1. However, they activated it again in 2022.11.2. Thus it should work again when there's a new vw web-vault release.~~

Ah, ok, it is strange that it works via the web-vault. I think that passwordless login might mean something other than FIDO2. In this case it is a Chrome plugin issue. Let's see what happens when they update it. The browser plugins are the only clients that haven't been updated to 2022.11.x yet.

What does the vw log say? Are there any error messages?

P.S.: It's way past my bed time, thus I'm heading to bed. Please don't think that I am ignoring your reply.

@tessus commented on GitHub (Dec 12, 2022): ~~Bitwarden deactivated passwordless login in 2022.11.1. However, they activated it again in 2022.11.2. Thus it should work again when there's a new vw web-vault release.~~ Ah, ok, it is strange that it works via the web-vault. I think that passwordless login might mean something other than FIDO2. In this case it is a Chrome plugin issue. Let's see what happens when they update it. The browser plugins are the only clients that haven't been updated to 2022.11.x yet. What does the vw log say? Are there any error messages? P.S.: It's way past my bed time, thus I'm heading to bed. Please don't think that I am ignoring your reply.

OVERLORD commented

2026-02-05 00:54:33 +03:00

@BlackDex commented on GitHub (Dec 12, 2022):

WebAuthn/FIDO2 is a totally different feature then Passwordless login.

I would check your reverse proxy settings that it isn't blocking iframe's or any other security headers which could interfere with these features. Vaultwarden already has all the needed security headers activated and configured where they need to be implemented. For all the popup screens it needs to be disabled, but if the reverse proxy adds some of there own globally, that could mess everything up.

@BlackDex commented on GitHub (Dec 12, 2022): WebAuthn/FIDO2 is a totally different feature then Passwordless login. I would check your reverse proxy settings that it isn't blocking iframe's or any other security headers which could interfere with these features. Vaultwarden already has all the needed security headers activated and configured where they need to be implemented. For all the popup screens it needs to be disabled, but if the reverse proxy adds some of there own globally, that could mess everything up.

OVERLORD commented

2026-02-05 00:54:35 +03:00

@Nyxtorm commented on GitHub (Dec 12, 2022):

@tessus,

Here is vw log during authentication, no more:

[2022-12-12 11:41:59.208][request][INFO] POST /api/accounts/prelogin
[2022-12-12 11:41:59.208][response][INFO] (prelogin) POST /api/accounts/prelogin => 200 OK
[2022-12-12 11:41:59.263][request][INFO] POST /identity/connect/token
[2022-12-12 11:41:59.291][error][ERROR] 2FA token not provided
[2022-12-12 11:41:59.291][response][INFO] (login) POST /identity/connect/token => 400 Bad Request

P.S.: It's way past my bed time, thus I'm heading to bed. Please don't think that I am ignoring your reply.

Haha no problem of course.

@BlackDex,

I don't remember changing my Nginx configuration for a long time, and I didn't have this problem before. I couldn't say exactly how long I've had it though, but for several weeks now for sure. I have no output in my nginx error logs.

Also, WebAuthn/FIDO2 authentication works fine from Android, Windows client or the web-vault.

Thank you both for your help 👍 and sorry for my English.

@Nyxtorm commented on GitHub (Dec 12, 2022): @tessus, Here is vw log during authentication, no more: ``` [2022-12-12 11:41:59.208][request][INFO] POST /api/accounts/prelogin [2022-12-12 11:41:59.208][response][INFO] (prelogin) POST /api/accounts/prelogin => 200 OK [2022-12-12 11:41:59.263][request][INFO] POST /identity/connect/token [2022-12-12 11:41:59.291][error][ERROR] 2FA token not provided [2022-12-12 11:41:59.291][response][INFO] (login) POST /identity/connect/token => 400 Bad Request ``` > P.S.: It's way past my bed time, thus I'm heading to bed. Please don't think that I am ignoring your reply. Haha no problem of course. --- @BlackDex, I don't remember changing my Nginx configuration for a long time, and I didn't have this problem before. I couldn't say exactly how long I've had it though, but for several weeks now for sure. I have no output in my nginx error logs. Also, WebAuthn/FIDO2 authentication works fine from Android, Windows client or the web-vault. Thank you both for your help 👍 and sorry for my English.

OVERLORD commented

2026-02-05 00:54:40 +03:00

@Nyxtorm commented on GitHub (Dec 12, 2022):

Looking a little bit more, I notice that it's this security option that I add on Nginx that blocks the display:

add_header X-Frame-Options "SAMEORIGIN" always;

But I don't understand why it only affects WebAuthn/FIDO2 (Duo Security works for example, it seems to me that it is also an iframe?) I wish I didn't need to remove this security option on my Nginx configuration.

@Nyxtorm commented on GitHub (Dec 12, 2022): Looking a little bit more, I notice that it's this security option that I add on Nginx that blocks the display: ``` add_header X-Frame-Options "SAMEORIGIN" always; ``` But I don't understand why it only affects WebAuthn/FIDO2 (Duo Security works for example, it seems to me that it is also an iframe?) I wish I didn't need to remove this security option on my Nginx configuration.

OVERLORD commented

2026-02-05 00:54:43 +03:00

@BlackDex commented on GitHub (Dec 12, 2022):

Looking a little bit more, I notice that it's this security option that I add on Nginx that blocks the display:
add_header X-Frame-Options "SAMEORIGIN" always;
But I don't understand why it only affects WebAuthn/FIDO2 (Duo Security works for example, it seems to me that it is also an iframe?) I wish I didn't need to remove this security option on my Nginx configuration.

That specific header should not be added for all the connector screens, like webauthn, duo, sso etc...
We do not send that header, and others for those pages. See b7c9a346c1/src/util.rs (L44)

@BlackDex commented on GitHub (Dec 12, 2022): > Looking a little bit more, I notice that it's this security option that I add on Nginx that blocks the display: > > ``` > add_header X-Frame-Options "SAMEORIGIN" always; > ``` > > But I don't understand why it only affects WebAuthn/FIDO2 (Duo Security works for example, it seems to me that it is also an iframe?) I wish I didn't need to remove this security option on my Nginx configuration. That specific header should not be added for all the `connector` screens, like webauthn, duo, sso etc... We do not send that header, and others for those pages. See https://github.com/dani-garcia/vaultwarden/blob/b7c9a346c1f7f664f2bda997632cb14fdd55b94d/src/util.rs#L44

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#1423