StartAuthentication method is encoding the userHandle twice from version v10.0.0

[DivyaSampath04]

Below is one of the change in @simplewebauthn/browser@v10.0.0
Additionally, startRegistration() will base64url-decode user.id before calling WebAuthn. During auth startAuthentication() will base64url-encode userHandle in the returned credential. This should be a transparent change for RP's that simply feed @simplewebauthn/server options output into the corresponding @simplewebauthn/browser methods.

Issue:
startAuthentication method is already returning userHandle in base64 encoded format.After upgrading to latest version, userHandle is being encoded twice which is impacting the existing webAuthn user during authentication whereas new registration and authentication works fine.

I am using only the browser package v13.0.0 and using a different server strategy for my app.

Reproduction Steps

After upgrading to latest v13.0.0, authentication of existing users fail.

Expected behavior

Exsiting users authentication should not be affected

[MasterKale]

Hello @DivyaSampath04, I'm sorry to hear about the trouble you're having here. It sounds like for your use case you might be able to use the base64URLStringToBuffer and bufferToBase64URLString helpers exported from @simplewebauthn/browser on response.userHandle when you get a return value from startAuthentication().

Does something like this work?

import { bufferToBase64URLString, startAuthentication } from '@simplewebauthn/browser';

const response = await startAuthentication({
  optionsJSON: { challenge: bufferToBase64URLString(new Uint8Array([1, 2, 3, 4])) },
});

// Double-encoded userHandle out of v10+
if (response.response.userHandle) {
  // Decode one layer so you get back the original base64url-encoded userHandle
  response.response.userHandle = new TextDecoder().decode(
    base64URLStringToBuffer(response.response.userHandle),
  )
}

[DivyaSampath04]

Double decoding works but I would like to know why the userHandle is encoded again when it is already returned in encoded format before v10.
This creates additional complexity in differentiating existing and new users from v10+.

[MasterKale]

I am using only the browser package v13.0.0 and using a different server strategy for my app.

Officially I can only meaningfully offer guidance for RPs using @simplewebauthn/browser with @simplewebauthn/server.

The rationale for this change is documented in #530. There's additional conversation about this change that may interest you.

Is it not possible to look up users by credential ID instead?

[joostdebruijn]

I encountered this problem after upgrading to v10 as well (see #563). To address this, I implemented a solution that flags all pre-v10 registered authenticators in the database and an additional decoding step on the server-side.

[danielpizarro]

@joostdebruijn I'm having the same problem

[joostdebruijn]

@joostdebruijn I'm having the same problem

I suggest you follow a similar approach as I did. In this way it's non-breaking, however you need to document in your server-side code why you're doing this.