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

Collapse
3: Re: Preview: WebAuthn / Passkeys support for OpenACS (passwordless login) (response to 1)
Posted by Gustaf Neumann on 01/10/26 09:36 AM

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.