+1

since BitWarden jumps in ahead of native browser (why?) it stops all localhost development using WebAuthn being workable, unless in a browser where the BitWarden chrome extension has been disabled

This also made me go insane debugging today to find out this was Bitwarden related and not my own WebAuthn code. Please at least update the error message so that it's easy to know that it is related to Bitwarden ;)

+1

since BitWarden jumps in ahead of native browser (why?) it stops all localhost development using WebAuthn being workable, unless in a browser where the BitWarden chrome extension has been disabled

I agree, after disabling BitWarden webauthn works as expected

I just ran into this too. Seems like it's coming from

There's a simple window.isSecureContext it could check, but maybe it doesn't have access to the window

At the very least, maybe something like

if (parsedOrigin.hostname == undefined 
    || !(
        params.origin.startsWith("https://") 
        || (params.origin === 'localhost') 
        || params.origin.endsWith('.localhost')
    )
) ...

If @barryp's solution is acceptable could we put this into a PR or is further consideration necessary? I have to enable & disable bitwarden when developing locally

I might need some tweaking such as adding 127.0.0.1 and .local domains maybe? Either way there some to be little to no interest from the Bitwarden team on this issue.

Hey, while I mostly work on Bitwarden passwordless.dev I'm just updating that we're looking to fix this in a way that aligns with the WebAuthn specification.

This started being an issue for me today.

Hey, while I mostly work on Bitwarden passwordless.dev I'm just updating that we're looking to fix this in a way that aligns with the WebAuthn specification.

Awesome. Any news on this?

+1 this sucks ass

@carlos-menezes See w3c/webauthn#2018

@carlos-menezes and others: Since w3c/webauthn#2018 was merged in the spec we will move forward and allow http://localhost:* for passkeys in bitwarden. I don't have a date, but my guess is that it won't be long.

Thanks for reporting this.

Awesome, great to hear!

Hey there!

Thanks to @coroiu, this issue will be resolved pretty soon, but I have a workaround and I hope this becomes useful for some.

I'm working on a project with Next.js and WebAuthn, and to bypass this limitation, I've created an HTTPS proxy for the development environment.

If you want to try this workaround, first install dependencies by following command:

npm i -D concurrently http-proxy

And then create https-server.js file in root of the project:

import fs from 'node:fs';
import path from 'node:path';
import proxy from 'http-proxy';

proxy
  .createServer({
    // openssl req -x509 -sha256 -nodes -newkey rsa:2048 -days 365 -keyout localhost.key -out localhost.crt
    ssl: {
      key: fs.readFileSync(path.resolve('localhost.key')),
      cert: fs.readFileSync(path.resolve('localhost.crt')),
    },
    target: {
      host: 'localhost',
      port: 3000,
    },
    ws: true,
  })
  .listen(3001);

Now run the dev server by following command:

concurrently --raw --kill-others "next dev" "node https-server.js"

Also, make sure that localhost is not excluded in extension settings.