AuthenticatorAssertionResponseValidator->check => Invalid user handle

[rico]

Hi, I suddenly have a problem with some my sites, where AuthenticatorAssertionResponseValidator->check fails with the exception message Invalid user handle.

$credentialUserHandle contains the correct user id, but $responseUserHandle (AuthenticatorAssertionResponse->getUserHandle) is always null.

Interestingly, if I use Safari instead of Chrome, the problem does not exist.

I already reset the passkey in the browser and deleted the authenticators in the DB to start over - without success. What could lead to such a problem?

Thanks a lot!

[Spomky]

Hello @rico,

Thank you for starting this discussion.
Have you read #390 and #362 (comment)?

As mentioned, browsers and platforms do not necessarily support passkeys/discoverable credentials.
Your application should detect the capabilities and have scenarios for both cases:

1. Start the authentication process by using passkey (=$userHandle is not passed as 5th argument of the check method)
2. In case of failure, ask the user identifier (username, email...) and try again with all known user authenticators and the $userHandle as 5th argument of the check method

[rico]

Hi @Spomky - thank you very much for the response. I tried a few things discussed in the linked issues. It didn't help. But once I reset my code and tried again, it worked. I don't have an idea what happened, but suspect an issue with the frontend library (SimpleWebAuthn).

Thanks again for your support.

[Spomky]

Hi @rico,

Many thank for your support. I really appreciate.
I reopen this issue, because I am not sure it is a bug from SimpleWebAuthn. This library is really well designed and fully compliant with the spec.
My assumption is that the user data sent during the const resp = await fetch('/generate-authentication-options'); call (<= from the documentation) is not complete.
This is correct if the authenticator supports discoverable credentials, but not enough for other ones.
It is then mandatory to sent the username as a JSON request body:

const resp = await fetch('/generate-authentication-options', {
    method: 'POST',
    headers: {'Content-Type': 'application/json'},
    body: {username: "john.doe"}
});

The response options will contain the user handle and will be passed to AuthenticatorAssertionResponseValidator->check.

[rico]

Hi @Spomky you are very welcome and I am the one to thank!

My assumption is that the user data sent during the const resp = await fetch('/generate-authentication-options'); call (<= from the documentation) is not complete.

Sorry, but I couldn't find that part in the documentation. Can you post a link to the where I can find it?

And what do you mean with not complete - a mistake on my side?

If this is the step where I get the PublicKeyCredentialEntity and PublicKeyCredentialRequestOptions from the server, I'm already passing the username (which in my case is the email) to the server...

I am basically following the implementation here: https://blog.joe.codes/implementing-passkey-authentication-in-your-laravel-app. Just using Vue instead of Alpine.js.

[Spomky]

Excellent! I was not aware of this Laravel implementation. That's a good news for the Laravel community.

There are 3 reasons for this exception to be thrown:

• The user handle is know (e.g. the user submitted its username)
  • [1] The used credential is not associated to the user (line 159 of AuthenticatorAssertionResponseValidator)
  • [2] The user handle associated to the used credential is different from the one declared in the options (line 163)
• The user handle is not know (e.g. trying to use passkey/discoverable credentials)
  • [3] The browser or the authenticator does not support this feature and the returned assertion has no user handle (line 168)

You mentioned you used passkeys and $responseUserHandle so I assumed you are in the case [3] i.e. you don't know the user and the exception is thrown from the line 168. To me, this means passkey/discoverable credentials is not supported and you must find the user handle first and pass the value as 5^th of the method check.

[rico]

Excellent! I was not aware of this Laravel implementation. That's a good news for the Laravel community.

Yes it is! According to a tweet, the author is also thinking about making a package out of it.

You mentioned you used passkeys and $responseUserHandle so I assumed you are in the case [3]

Definitely.

To me, this means passkey/discoverable credentials is not supported and you must find the user handle first and pass the value as 5th of the method check.

I tracked this back to PublicKeyCredentialLoader:139. $response['userHandle'] is not set.

I guess this is value should be set in the browser?

The thing with this issue is, that sometimes it works, and then it doesn't - same code and browser. Any suggestions what I can check?

I even compared the responses for Safari (where it always works) and Chrome, but can't find any major differences ...

[rico]

I gave it another try today - could still not figure it out. As a workaround, I am storing the user handle (PublicKeyCredentialUserEntity->id) in the session and pass it to AuthenticatorAssertionResponseValidator::check().