Re-register passkey in client side discoverable credentials flow

Hi there, we are currently playing around with passkeys and especially with the client side discoverable credentials flow as we don't require any email (or account id) from our users.

Our current authentication flow: request challenge from server sign challenge with existing passkey send signed challenge to server server returns auth result and OAuth token to authenticate further requests.

Our registration flow in case no passkey exists: request credential registration options from server (includes a UUID which is used to create the passkey as we don't require email/user name from the user create passkey locally upload public key to server

After the registration has completed the authentication process will be retried.

Let's look at following example:

The user has successfully created a passkey for our platform and is able to authenticate against the server. All good so far. For some arbitrary reason the public key on the server gets deleted (possibly by deleting the account, or other reasons). The next time the user tries to authenticate against the platform the authentication is rejected, which is correct. The logical next step would be to register a new passkey. But there is the catch. By registering a new key a new UUID will be requested from the server which will create a new passkey. As we are using the client side discoverable credentials we don't know the user id with which the passkey has been created. The next time the user tries to authenticate he will be prompted with the action sheet to select one of the two existing keys.

I would like to know whether there is a way to re-register an existing passkey in order to prevent the key selection step.

Additionally, is there any way to customize (use a different userId) the passkey action sheet message? "Do you want to sign in <platform> with you saved passkey for '4636bbbf-27fa-4a54-b892-a2aec8b0d68e'?" doesn't help the user a lot, especially when there are multiple keys existing.

Thanks for your support!

Up vote post of biegl Down vote post of biegl
535 views
Posted by
biegl
Reply
Add a Comment

Replies

I see two different questions here, so I'll try to answer both :)

1. After an account is deleted, what can you do about that no-longer-useful passkey, especially if the user creates a new account?

Let's take the passkey out of the equation for a second and imagine it was a password-based account which also uses UUIDs for usernames. I (the user) had an account, with my password stored in my password manager, and deleted that account on the server. I now have this password in my password manager for an account that no longer exists. I then go to create a new account, and since the username (UUID) is different, I now have two different accounts in my password manager, even though only one exists on the server. It's not ideal, but this problem isn't unique to passkeys.

If the usernames were the same, my password manager would have updated the saved account in-place, rather than creating a second one. But since they're different, the password manager can't know whether "I'm creating a new account because the old one no longer exists" or "I'm creating a new account because I want two accounts". The same is true for passkeys, except the primary key is the userID instead of username. If you create a new passkey with the same userID as an existing one, the existing passkey gets updated. If you create a new passkey with a different userID, the passkey manager can't know whether you already deleted the other account on the server or you just want two passkeys.

2. How do you customize the username in the sheet?

The string that's shown in the sheet is the name field for the passkey. This should be a user-readable string to identify the account. The value doesn't matter as it's only used for display purposes, so it could be something like a nickname for the account. It's also never returned to the server, so you don't need to worry about conflicts. The userID on the other hand is never visible to the user, does get returned to the server, and does need to be unique for every account. For that, continuing to use a UUID makes sense.

Posted by
garrett-davidson
Up vote reply of garrett-davidson Down vote reply of garrett-davidson
Add a Comment