Forum OpenACS Development: Re: Preview: WebAuthn / Passkeys support for OpenACS (passwordless login)

Unfortunately, I currently don’t have a Linux client available for testing. From reports, desktop Linux browsers appear to have limited support for passkey discovery: passkeys can be created and stored, but are not always discoverable in a passkey-first login flow.

Passkey discovery requires a platform credential provider (such as iCloud Keychain on Apple platforms or Windows Hello on Windows). Without such a provider, browsers may support passkeys, but cannot reliably offer automatic passkey discovery during login.

The following client platforms are reported to work well with passkey discovery:

- Safari on macOS / iOS
- Chrome on macOS / Windows
- Edge on Windows
- Chrome on Android

This means, testing via mobile devices is much better supported. Do you have any of these to test?

In general, it should be possible to avoid passkey discovery by supporting additionally an identifier-first workflow. The crypto management will be the same, but parameterization and interactions will change. i have to look into the details.
I used my Android 16 and tried with Chrome and Firefox, but the result was the same as before.

Please note that I'm already using passkeys on my smartphone to log into service like Google, Dropbox etc.

Claudio

Hi Claudio,

thanks for testing and reporting this.

I checked the database on openacs.org, and you do have a passkey registered from your Android device (Chrome on Android, reporting as Android 10), so registration itself clearly worked.

What has changed since the earlier tests is the login flow, not the underlying WebAuthn support:

  • We no longer rely on a pure passkey-first approach.
  • Instead, the default is now auto mode, which works as follows:

  • If the login field is empty → try passkey-first (credential discovery).

  • If an email/username is present → use identifier-first (restrict WebAuthn to passkeys registered for that account).

  • If passkey-first is not supported or does not return a credential, the UI asks for the identifier and retries via identifier-first.

This change was necessary because passkey discovery is not reliably supported on all platforms and browser combinations.

On Android, passkey-first should work in principle, but behavior still varies depending on browser, account integration, and platform state. Identifier-first is therefore the robust path that works everywhere.

Could you please try the following once more? Since you have already registered a passkey before, you should see now the "sign-in with passkey" under the login form. Then click “Sign in with passkey”. If no passkey is registered and no ident (on this site the email address) was entered, you will be prompted to provided it.

If this still fails, we can look at the server logs for the exact WebAuthn error returned by the browser.

All the best -g

I just retried on my smartphone, but I got no chance to sign in with passkey.

Claudio

Hi Claudo,

Does this mean, you saw no "sign-in with passkey" button? To reduce the guess-work, i have added a diagnostics page: open on otpnacs.org the page "/webauthn/diagnostics" and clock "send report to server-log", then i should see the relevant details.

Again, many thanks for your help
-g

Hi Gustaf,

I don't see the sign-in with passkeys button. I executed the diagnostica and sent the report to server-log with diag_id=CF2E1BE269683D3E7E9164B079658E979.
I also tried the Test 1 and Test 2, both resulting with:
"ok": true,
"gotAssertion": true,
"id": "LoJx1jYWiyfuPTcJwdx1kA",
"type": "public-key"

Claudio

Thanks for testing and for sending the diagnostics — your report shows that passkeys and conditional mediation are supported and working on your device. I have changed the "display button" logic to be more liberal.

The “Sign in with passkey” button should now appear; if it still does not, please re-run /webauthn/diagnostics (report is further extended) and send me the new diag_id so I can inspect the gating logic on the server side.

The button doesn't appear yet.
I sent the report and the diag_id Is 7103DE6A7F77A045BE2E4CA420BCB9A83

Claudio

Thanks — your diagnostics show WebAuthn works, so this looks like a cached login JavaScript issue (the updated JavaScript file was not fetched from the server). I’ve updated the login page to force a fresh download of passkey-login.js;

Could you please go to the login page again and check whether the “Sign in with passkey” button appears now?

Great! Now it works perfectly.
Many thanks!

Claudio

Dear Claudio,

great to hear — thanks for testing and for your patience!

Part of the issue turned out to be a cached JavaScript file in the browser; after a refresh, things behaved as expected. We’ve also improved the package by adding a Passkey diagnostics link directly next to the passkey management on /pvt/home, so it’s easier to collect useful information if something doesn’t work.

We’re still looking into further improvements around the visibility of the “Sign in with passkey” button, especially on systems without passkey discovery.

Thanks again for helping to shake this out!
-g