You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
StartAuthentication method is encoding the userHandle twice from version v10.0.0 #666
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
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';constresponse=awaitstartAuthentication({optionsJSON: {challenge: bufferToBase64URLString(newUint8Array([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 userHandleresponse.response.userHandle=newTextDecoder().decode(base64URLStringToBuffer(response.response.userHandle),)}
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+.
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.
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.
Repository owner locked and limited conversation to collaborators on Feb 25, 2025
Activity
MasterKale commentedon Jan 17, 2025
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
base64URLStringToBufferandbufferToBase64URLStringhelpers exported from @simplewebauthn/browser onresponse.userHandlewhen you get a return value fromstartAuthentication().Does something like this work?
DivyaSampath04 commentedon Jan 17, 2025
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 commentedon Jan 17, 2025
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 commentedon Jan 19, 2025
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 commentedon Jan 24, 2025
@joostdebruijn I'm having the same problem
joostdebruijn commentedon Jan 25, 2025
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.