v2.9.3

Challenge emails are now emailed by Passlock by default

Mailbox challenge emails will be emailed to the recipient via Passlock infrastructure unless sendEmail: false is passed to the createMailboxChallenge call.

v2.9.2

Remove redundant code relating to old v1 endpoints

v2.9.1

Upgrade dependencies

v2.9.0

Passlock can now email mailbox verification challenges

Added

• @passlock/server mailbox challenge creation now accepts sendEmail: true to request Passlock-managed delivery for one-time-code emails. Omitting sendEmail, or passing sendEmail: false, preserves the existing generate-only behavior and keeps returning the generated code and rendered message for custom delivery.

• @passlock/server and the POST /v2/:tenancyId/challenges REST API now accept an optional recipient name when creating mailbox challenges. The name is used for email delivery only and does not affect challenge scope, lookup, invalidation, or verification.

v2.8.0

Server initiated passkey updates and deletions

Introduces a more reliable, token-based passkey lifecycle flow by making both passkey deletion and update operations exchange a backend-issued token that the client uses to complete local/device cleanup, aligning behavior with registration; it also removes support for browser-initiated passkey updates/deletions so all passkey changes are coordinated through the intended backend-driven process; and it clarifies update semantics by making it explicit that only all passkeys for a given userId can be updated, since WebAuthn does not support targeting individual passkeys.

Added

• Delete passkey now uses an exchangeable token to synchronize backend and frontend records. This process is similar to that used for passkey registration. The backend initiates the process, returning a token. The frontend uses this token to perform its client-side cleanup.

• Update passkey now uses an exchangeable token to synchronize backend and frontend records. This process is similar to that used for passkey registration. The backend initiates the process, returning a token. The frontend uses this token to update the device passkeys.

Removed

• Browser-initiated passkey updates and deletions are no longer possible

Changed

• It is now only possible to update all passkeys for a given userId. Previous versions of @passlock/browser implied it was possible to update a specific passkey, however the WebAuthn specs don't actually permit this.

v2.7.0

Added

New skill to support versioning of workspace packages.

Removed

Changeset package as we now use Codex/Claude

@passlock/browser/safe, @passlock/browser/unsafe, @passlock/server/safe and @passlock/server/unsafe. Every client and function is now safe by default.

Changed

Determine passkey RP ID during registration or authentication initiation/authorization instead of pulling it from the tenancy settings.

The RP ID must now be provided by the caller:

import { Passlock } from "@passlock/server";

const passlock = new Passlock({
  tenancyId,
  apiKey
});

await passlock.authorizePasskeyRegistration({
  rpId: 'example.com',
  ...
});

await passlock.authorizePasskeyAuthentication({
  rpId: 'example.com',
  ...
});  

v2.6.0

Although linking of passkeys to user accounts happens in backend code, it was possible for an untrusted client to create a passkey. Following this release passkey registration will first require backend authorisation.

Changed

• Server side passkey registration preparation. This prevents untrusted clients from registering passkeys without proper authorization.
• Updated CHANGELOG.md format following Keep a Changelog.

Added

• (Optional) Server side passkey authentication preparation. Allows developers to supply known passkey IDs (allowCredentials) and other authentication options directly in backend code instead of threading them through the frontend.