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

Dear all,

I would like to announce a preview / early adopter implementation of WebAuthn (Passkeys) for OpenACS.

This work adds passwordless authentication based on the W3C WebAuthn standard and the FIDO2 ecosystem, allowing users to log in using passkeys instead of passwords.

What is WebAuthn / Passkeys?

WebAuthn is a W3C standard that enables strong, phishing-resistant authentication using public-key cryptography. In practice, this allows users to authenticate via:

• Face ID / Touch ID (Apple devices)
• Fingerprint sensors
• Platform authenticators (iOS, Android, macOS, Windows)
• Security keys (e.g. YubiKey)

The private key never leaves the device. Only signed challenges are sent to the server, verified against a stored public key.

Modern browsers (Chrome, Safari, Firefox, Edge) support WebAuthn natively.

What does this provide in OpenACS?

This preview implementation adds:

• Registration of passkeys per user and site
• Login via passkey (“Sign in with passkey”) alongside the existing password login
• Support for multiple passkeys per user (e.g. phone + laptop)
• Listing and deletion of registered passkeys by the user
• Proper handling of browser/device differences
• Secure per-origin handling using Relying Party IDs (rpId)

Passwords are not removed — passkeys are an additional authentication option.

User experience

From the user’s perspective:

• A user can register a passkey from their device
• Subsequent logins can use Face ID / fingerprint / platform authentication
• No password needs to be typed
• On supported devices, passkeys can be synced securely (e.g. via iCloud Keychain)

The exact experience depends on the device capabilities.

Site administrator options

For site admins:

• WebAuthn can be enabled per OpenACS installation
• The Relying Party ID (rpId) can be configured (defaults sensibly to the server name)
• Works with standard OpenACS subsites and login flows
• No external service or cloud dependency is required

Technical requirements

This preview requires recent NaviServer versions, specifically:

• NaviServer with CBOR support (RFC 8949)

• Extended crypto support for EC keys, including:

  • Importing and creating keys from affine coordinates
  • COSE / WebAuthn-compatible key handling
  • OpenSSL with modern EC support

The docker version gustafn/naviserver, ... gustafn/openacs contains all required C-level support (but the webauthn package is not included since to released)

Status and expectations

This is a preview / early adopter feature:

• The protocol handling is standards-based and tested
• UX and integration details may still evolve
• Feedback from developers and early testers is very welcome

The goal is to make WebAuthn a first-class authentication option in OpenACS, while keeping full backward compatibility with existing password-based logins.

Live preview on openacs.org

The new WebAuthn / passkey support is installed for testing on openacs.org.

• Registered users can manage their passkeys on the /pvt/home page (register new passkeys, list existing ones, and delete them).
• After a passkey has been registered, the login page will offer a “Sign in with passkey” option in addition to the regular password login.

Please note: In the current preview implementation, logins via passkey do not extend sessions automatically. When a session expires, the user is logged out and needs to authenticate again (either via passkey or password). This behavior is intentional for now and may be refined based on feedback.

The current setup requires some modifications of acs-subsite. i have to make up my mind, when and where i will make the new webauthn package available

More details, code pointers, and setup instructions will follow.

Best regards,
-g

WebAuthn / Passkeys in OpenACS – Clarifications on Standards, Vendors, and Implementation Choices

This post clarifies what is inherent to WebAuthn, what depends on platform vendors, and what is a deliberate design decision in the current OpenACS implementation. The goal is to avoid misattributing behavior to the wrong layer.

---

1. Inherent properties of WebAuthn (standard behavior)

These aspects are defined by the WebAuthn / FIDO2 standards and apply to all compliant implementations.

Relying Party ID (rpID)

• Credentials are strictly bound to an rpID
• The rpID is usually a domain name (e.g. openacs.org)
• Browsers enforce rpID matching; servers cannot override this

This means:

• Credentials created for localhost are not usable for openacs.org
• Ports are not part of the rpID (but may appear in vendor UIs)

---

Credentials are asymmetric cryptographic keys

• A passkey is a private key held by the authenticator
• The server stores only the public key
• No shared secret is transmitted or stored

This is not configurable behavior — it is the core security model.

---

Multiple credentials per user are normal

• WebAuthn explicitly supports multiple credentials per user
• Each registration produces a distinct credential ID
• Servers must be prepared to manage lists of credentials

There is no “update passkey” operation in the standard — only create and delete.

---

Discoverable vs non-discoverable credentials

• Discoverable credentials (“resident keys”) allow passkey-first login
• Non-discoverable credentials require a prior user identifier

Whether discoverable credentials are used is a server choice, but their behavior is defined by the standard.

---

2. Vendor- and platform-specific behavior

These behaviors are outside the control of OpenACS and vary by OS and browser.

Passkey synchronization

• Apple: passkeys are synced via iCloud Keychain
• Google/Chrome: synced via Google Password Manager
• Firefox: often browser-local (depending on platform)
• Hardware keys: portable but not synced

As a result:

• A passkey created in one browser may appear in another
• The same credential may be usable across multiple browsers on the same device

---

UI labeling and grouping

• Platform UIs decide how passkeys are grouped and labeled
• Some systems merge historical entries (e.g. old :8000 sites)
• Users may see only one entry even if multiple credentials exist server-side

This is a presentation artifact, not a protocol issue.

---

Browser password manager prompts

• Browsers strongly promote password managers
• Passkey prompts and password prompts may appear together
• Suppressing password UI is browser-specific and limited

This is not something WebAuthn or OpenACS can reliably control.

---

3. OpenACS implementation choices (preview phase)

The following points describe current design decisions, not protocol requirements.

---

Passkey-first login (current choice)

The implementation currently prefers passkey-first login using discoverable credentials.

Why:

• aligns with platform vendor guidance
• simpler UX for users with passkeys
• avoids an extra “enter email first” step

Alternative (not yet implemented):

• email/username-first login
• server-side filtering of credentials
• clearer for multi-account scenarios

This may become configurable.

---

When the passkey login button is shown

Currently shown only when:

• WebAuthn is supported by the browser
• the WebAuthn package is enabled
• there is a reasonable hint that a passkey may exist

This avoids confusing first-time users.

---

Session expiration behavior

In the preview:

• passkey logins do not silently re-authenticate
• session expiration triggers a logout
• reauthentication is explicit

This is a conservative choice for testing and may change.

---

Credential management UI

OpenACS:

• lists all credentials per user
• shows labels derived from User-Agent
• allows explicit deletion

Labeling is informational only and not security-relevant.

---

rpID configuration

OpenACS:

• derives the default rpID from the server configuration name
• allows explicit override via package parameter
• validates rpID at startup

This avoids accidental misconfiguration and makes the security boundary explicit.

---

Summary

Layer	What it controls
WebAuthn standard	Cryptography, rpID binding, credential model
Platform vendors	Syncing, UI, password manager behavior
OpenACS	Login flow, UX choices, credential management, defaults

Understanding these layers helps distinguish what can be tuned from what must be accepted as given.

sorry! I made a typo for the intensified logging of web user agents on the site in the passkey registration code. This is fixed right now.

Have you registered the passkey on the same device you are trying to log-in? Once you have done so, and you have logged out, a later /register shows the left image. Where there is just a session-timeout (the case, where OpenACS fills out the email-address for you), one sees the right login screen. Both are with recent iOS and Safari on an iPhone.

Hi Claudio,

The passkey must be created on the same device where you are testing the login, so that it is available to the platform’s credential store on that device.

Could you please confirm that the passkey was created on the same device where you later tried to sign in?

In the current preview, the “Sign in with passkey” option is shown conservatively on the client side and may still be refined based on feedback like yours.

Many thanks for testing! -g

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?

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

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

Claudio

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

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

Claudio

Great! Now it works perfectly.
Many thanks!

Claudio

After the initial feedback, the new code moved away from a pure passkey-first login because it is not reliable across all platforms (notably Linux desktops, and sometimes Android browser combinations).

The current design supports three modes:

1) passkey (passkey-first)

• Browser is asked to discover a credential without any user identifier.
• Works well on Apple platforms and often on Android.
• Fails silently on some platforms (notably Linux desktop browsers).

2) identifier (identifier-first)

• User enters email/username first.
• Server restricts WebAuthn to passkeys registered for that account (allowCredentials).
• Works reliably on all platforms.
• This is now the robust fallback.

3) auto (default)

• Decides per click, not per browser:

• If identifier field is non-empty → identifier-first

• If identifier field is empty → try passkey-first
• If passkey-first fails (e.g. no discoverable credentials), the UI prompts the user to enter an identifier and retries via identifier-first.
• No user-agent sniffing is relied upon anymore.

To sum up, “Passkey-first” works on many devices (Apple, often Android), but is not consistently supported everywhere. Rather than guessing based on browser/OS, the login flow now adapts dynamically and always has a reliable fallback.

I have installed the new version on openacs.org just now. Previously registered passkeys continue to work (no need to register passkeys again). The changes for the different authorization modes were mostly in JS, and a few in tcl (additional arguments, mode handling).

all the best -g