webauthnUserID and signals

[darthmaim]

Right now I am using a schema similar to the one described on the website, where each passkey has its own webauthnUserID. A user can have multiple passkeys.

Now if I want to use signals like signalAllAcceptedCredentials or signalCurrentUserDetails, I assume I have to call this multiple times for every passkey, as they have different user ids.

// assume we have these passkeys for user 'u1':
{ id: 'p1', webauthnUserID: 'foo', userId: 'u1' }
{ id: 'p2', webauthnUserID: 'bar', userId: 'u1' }

// for example after login I now need this
signalAllAcceptedCredentials({ rpId, userId: 'foo', allAcceptedCredentialIds: ['p1'] });
signalAllAcceptedCredentials({ rpId, userId: 'bar', allAcceptedCredentialIds: ['p2'] });
signalCurrentUserDetails({ rpId, name: 'Example', userId: 'foo' });
signalCurrentUserDetails({ rpId, name: 'Example', userId: 'bar' });

// I would much rather do this
signalAllAcceptedCredentials({ rpId, userId: 'u1', allAcceptedCredentialIds: ['p1', 'p2'] });
signalCurrentUserDetails({ rpId, name: 'Example', userId: 'u1' });

// even worse, when deleting a passkey I now have to explicitly keep track of the deleted passkey to be able to call this
signalAllAcceptedCredentials({ rpId, userId: 'deleted', allAcceptedCredentialIds: [] });

Am I understanding this correctly?

Is there a reason why the schema suggests unique webauthnUserID per passkey, instead of one webauthnUserID on the apps user entity, or even directly using the apps id of the user?

[MasterKale]

Is there a reason why the schema suggests unique webauthnUserID per passkey, instead of one webauthnUserID on the apps user entity, or even directly using the apps id of the user?

// I would much rather do this
signalAllAcceptedCredentials({ rpId, userId: 'u1', allAcceptedCredentialIds: ['p1', 'p2'] });
signalCurrentUserDetails({ rpId, name: 'Example', userId: 'u1' });

I, uh...huh. So yes, the ideal way to use signals is to have the same user ID value associated with all of a given user's passkeys.

But reviewing my guidance in the docs, I see how I may have inadvertently made life difficult for you by auto-generating user IDs on each call. In WebAuthn deployments I've built or talked with others who've built, some kind of system-wide user ID is generated for the user account before the passkey ceremony takes place. That user ID would get consistently used as, specific to SimpleWebAuthn, userID when calling generateRegistrationOptions(), so there'd not be a random user ID used in every ceremony for the same user. That way no matter how many passkeys the user registers, it would be the same value for Passkey.webauthnUserID in Additional data structures.

I don't know how satisfying a response this is, but one way I'd try to fix this problem is to first stop the bleeding by updating your generateRegistrationOptions() to specify the userID argument explicitly for the logged in user. That way subsequent passkey registrations for users will use a consistent user identifier (that's not an email address or other such PII) so that eventually you could get to only calling the signal API methods once per user.

For your existing users you're kinda stuck, though, because there's no signal API to update the user ID associated with a given passkey...that's pretty much an immutable value by design since user ID is used along with RP ID to map user credentials within a FIDO2 authenticator 😔

I also think I need to revisit the Passkey data structure and suggested DB schema. I probably need to move the passkeys.webauthn_user_id column to the users table and use the passkeys.internal_user_id foreign key in the passkeys table to look up users.webauthn_user_id, such that there ends up being a sole value for userId to use when calling the Signal APIs.

Sorry for the bad news here :(

[MasterKale]

fwiw if you want to pick your own user ID, I'd recommend not using something too simple like the database row ID. Instead I'd generate 18-24 random bytes per user and use that all over the place so that values in table columns like "row_id" aren't exposed to public APIs (as they could allow for enumeration attacks by attackers, especially if it's a simple incrementing number.)

[darthmaim]

Okay, so at least I understood everything correctly then.

Luckily almost all my users only have a single passkey, so with some smart migrations only a few passkeys will not receive signals (and signalUnknownCredential will still work for those).

Would be great if the docs and the suggested schema are updated and a paragraph about what the webauthn_user_id is used for and how it should be generated is added. There is also the generateUserID function exported from @simplewebauthn/server/helpers that currently is not mentioned anywhere in the docs.