Skip to content

feat(passkeys): Add passkey generate and validate challenge methods#20194

Open
nshirley wants to merge 1 commit intomainfrom
FXA-13061
Open

feat(passkeys): Add passkey generate and validate challenge methods#20194
nshirley wants to merge 1 commit intomainfrom
FXA-13061

Conversation

@nshirley
Copy link
Contributor

Because:

  • We now need to expose the passkey registration generation

This commit:

  • Adds new verifyRegistrationResponse and generateRegistrationChallenge service methods
  • Adds tests for new functions
  • Updates manager to expose checkPasskeyCount for use in service and manager

Closes: FXA-13061

Checklist

Put an x in the boxes that apply

  • My commit is GPG signed.
  • If applicable, I have modified or added tests which pass locally.
  • I have added necessary documentation (if appropriate).
  • I have verified that my changes render correctly in RTL (if appropriate).

Screenshots (Optional)

Please attach the screenshots of the changes made in case of change in user interface.

Other information (Optional)

Any other information that is important to this pull request.

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds service-level APIs for passkey (WebAuthn) registration by exposing challenge generation and registration response verification, and refactors passkey-limit enforcement into a reusable manager method.

Changes:

  • Add generateRegistrationChallenge and verifyRegistrationResponse to PasskeyService.
  • Refactor passkey limit enforcement into PasskeyManager.checkPasskeyCount and reuse it from registration flows.
  • Add/extend unit + integration tests covering the new service/manager behavior and updated error expectations.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.

Show a summary per file
File Description
libs/accounts/passkey/src/lib/passkey.service.ts Adds registration challenge generation + attestation verification logic, passkey name generation, metrics/logging.
libs/accounts/passkey/src/lib/passkey.service.spec.ts Adds unit tests for new service methods and passkey naming behavior.
libs/accounts/passkey/src/lib/passkey.manager.ts Extracts passkey-limit logic into checkPasskeyCount and switches limit error to AppError.
libs/accounts/passkey/src/lib/passkey.manager.spec.ts Updates unit tests for new AppError behavior and adds checkPasskeyCount coverage.
libs/accounts/passkey/src/lib/passkey.manager.in.spec.ts Updates integration assertions for limit error and adds integration coverage for checkPasskeyCount.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +120 to +122
if (!storedChallenge) {
// technically, this could be because the challenge expired, was already consumed, or never existed.
// However, we can't distinguish these cases, and in all cases the appropriate response is to reject the registration attempt.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comment here for why we don't validate the UID

Comment on lines +184 to +191
beforeEach(() => {
mockChallengeManager.validateChallenge.mockResolvedValue({
challenge: MOCK_CHALLENGE,
type: 'registration',
uid: MOCK_UID.toString('hex'),
createdAt: Date.now() - 1000,
expiresAt: Date.now() + 299000,
});
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving a comment for keeping track - on the surface this sounds good but I was thinking about the challenge manager during implementation and it doesn't feel like it should be responsible for checking the UID on the challenge. The UID exists as meta-data for consumers of the library to validate, but it also isn't guaranteed to exist. Authentication challenges for example don't take a UID so it won't be present.

That said, if Authentication should take a UID, I can always fix it! If all challenge types have a UID, then it's probably okay to validate in the manager

Because:
 - We now need to expose the passkey registration generation

This commit:
 - Adds new verifyRegistrationResponse and generateRegistrationChallenge
   service methods
 - Adds tests for new functions
 - Updates manager to expose checkPasskeyCount for use in service and
   manager

Closes: FXA-13061
@nshirley nshirley marked this pull request as ready for review March 17, 2026 20:42
@nshirley nshirley requested a review from a team as a code owner March 17, 2026 20:42
case 'nfc':
return 'NFC Security Key';
case 'hybrid':
return 'Passkey';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These names need to be localized. Also what if two passkeys have the same name? Should we add #1 #2 etc. after them to distinguish 🤔?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants