Correctly identifying a user for logging in

[akozlik]

Hi y'all,

I may be overthinking this or completely missing something but...

When I look at the authentication sample code for this project the user ID is hardcoded under

const user = inMemoryUserDeviceDB[loggedInUserId];

All of the documentation references retrieving the logged in user from a loggedInUserId

// (Pseudocode) Retrieve the logged-in user
const user: UserModel = getUserFromDB(loggedInUserId);

My question is - where are we pulling that loggedInUserId from if we don't have the user's ID because they haven't authenticated yet? We're supposed to pull the user's existing credentials but how can we do that without a user ID?

It's recommended to get the challenge via a GET request but if we're doing a GET call shouldn't we avoid sending any identifying info as URL params?

Everywhere I look has examples of implementing a process similar to this library but nobody shows info on how to get the actual identifying user ID. They're all pseudocode references without any info on how to actually pass that data up to the service.

I feel like a crazy person and I'm missing something obvious but I'd love to know what others do to pass up the user ID. I might be completely missing a key point of WebAuthn as well so if I'm off base please let me know.

Thanks in advance for anyone who can she some light.

[spendres]

The user ID is simply a unique key that is included in the signed passkey stored in the user's keychain. I use encoded ULIDs for unique user IDs; but there is no identifying information in the ID. It is used restore their session on the server when they login. import { Generator, encode_base32, } from ***@***.***/mod.ts"; const userID = gen.ulid_encoded();

> returns a string that looks like: "2T2E0WK074H2S8QCS4DGD6QTMP"

userID should really be thought of as a unique userInDex; like a key to a user Map,Table, or Record.

…

On Mon, Jul 24, 2023 at 11:24 AM Andrew Kozlik ***@***.***> wrote: Hi y'all, I may be overthinking this or completely missing something but... When I look at the authentication sample code for this project the user ID is hardcoded under const user = inMemoryUserDeviceDB[loggedInUserId]; All of the documentation references retrieving the logged in user from a loggedInUserId // (Pseudocode) Retrieve the logged-in user const user: UserModel = getUserFromDB(loggedInUserId); My question is - where are we pulling that loggedInUserId from if we don't have the user's ID because they haven't authenticated yet? We're supposed to pull the user's existing credentials but how can we do that without a user ID? It's recommended to get the challenge via a GET request but if we're doing a GET call shouldn't we avoid sending any identifying info as URL params? Everywhere I look has examples of implementing a process similar to this library but nobody shows info on how to get the actual identifying user ID. They're all pseudocode references without any info on how to actually pass that data up to the service. I feel like a crazy person and I'm missing something obvious but I'd love to know what others do to pass up the user ID. I might be completely missing a key point of WebAuthn as well so if I'm off base please let me know. Thanks in advance for anyone who can she some light. — Reply to this email directly, view it on GitHub <#420>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEVLYFDW6TE4HCTP7HACF3XR2HRZANCNFSM6AAAAAA2VYACQA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[spendres]

I meant... import { Generator, encode_base32, } from ***@***.***/mod.ts"; const gen = new Generator(); const userID = gen.ulid_encoded();

…

> returns a string that looks like: "2T2E0WK074H2S8QCS4DGD6QTMP" On Mon, Jul 24, 2023 at 5:35 PM Steven Endres ***@***.***> wrote: The user ID is simply a unique key that is included in the signed passkey stored in the user's keychain. I use encoded ULIDs for unique user IDs; but there is no identifying information in the ID. It is used restore their session on the server when they login. import { Generator, encode_base32, } from ***@***.***/mod.ts"; const userID = gen.ulid_encoded(); >> returns a string that looks like: "2T2E0WK074H2S8QCS4DGD6QTMP" userID should really be thought of as a unique userInDex; like a key to a user Map,Table, or Record. On Mon, Jul 24, 2023 at 11:24 AM Andrew Kozlik ***@***.***> wrote: > Hi y'all, > > I may be overthinking this or completely missing something but... > > When I look at the authentication sample code for this project the user > ID is hardcoded under > > const user = inMemoryUserDeviceDB[loggedInUserId]; > > All of the documentation references retrieving the logged in user from a > loggedInUserId > > // (Pseudocode) Retrieve the logged-in user > const user: UserModel = getUserFromDB(loggedInUserId); > > My question is - where are we pulling that loggedInUserId from if we > don't have the user's ID because they haven't authenticated yet? We're > supposed to pull the user's existing credentials but how can we do that > without a user ID? > > It's recommended to get the challenge via a GET request but if we're > doing a GET call shouldn't we avoid sending any identifying info as URL > params? > > Everywhere I look has examples of implementing a process similar to this > library but nobody shows info on how to get the actual identifying user ID. > They're all pseudocode references without any info on how to actually pass > that data up to the service. > > I feel like a crazy person and I'm missing something obvious but I'd love > to know what others do to pass up the user ID. I might be completely > missing a key point of WebAuthn as well so if I'm off base please let me > know. > > Thanks in advance for anyone who can she some light. > > — > Reply to this email directly, view it on GitHub > <#420>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAEVLYFDW6TE4HCTP7HACF3XR2HRZANCNFSM6AAAAAA2VYACQA> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

[teolag]

I completely agree with you @akozlik.

When we generateAuthenticationOptions it is allowed to not have any allowCredentials because we don't know anything about the user that is about to login right now. If allowCredentials is empty, the browser will show a list of available passkeys for the current domain.

After that, we want to verifyAuthenticationResponse. In the documentation it says:

// (Pseudocode) Retrieve the logged-in user
const user: UserModel = getUserFromDB(loggedInUserId);

How should we retrieve the logged in user? The only thing we can use from the client response is the credentialID as @spendres said, but it feels really wrong to search for that ID on all authenticatorDevices in ALL users? There must be a way to single out the user first and then find the authenticatorDevice that matches the authentication response?

[MasterKale]

My question is - where are we pulling that loggedInUserId from if we don't have the user's ID because they haven't authenticated yet? We're supposed to pull the user's existing credentials but how can we do that without a user ID?

Hello @akozlik, apologies for the delayed response! And thanks for contributing to the conversation, @spendres and @teolag.

The example project has historically been more about "passwordless" use of WebAuthn. This is where you are able to understand who the user is who's authenticating before calling WebAuthn. For example, by having the user submit their username, then you look up any credentials for that account and include them in allowCredentials. In this scenario, loggedInUserId would be the internal DB ID of the account record with the corresponding "email" value they submit to you first.

Passkey-centric flows are more about "usernameless" use of WebAuthn. In these scenarios you can't know even an email address to get to loggedInUserId. So instead what you do is call WebAuthn with an empty array for allowCredentials. This changes things up by having a user selecting a credential to generate a response to navigator.credentials.get() that the RP receives and then decides if it's one that's allowed to be used for authentication. When the WebAuthn response passes verification then the RP can do a bit more legwork to connect the credentialID to an internal user ID and then log in the user as that user ID.

Does that all make sense? This section of the docs is somewhat related to this discussion, if you haven't had a chance to read it I think it might help make more sense of all this:

https://simplewebauthn.dev/docs/advanced/passkeys

but it feels really wrong to search for that ID on all authenticatorDevices in ALL users?

@teolag Please don't use authenticatorDevices as inspiration for how to store which credentials belong to which users! It's an in-memory data structure that was easy to implement and doesn't need to worry about scaling to thousands of records.

Instead, for example, in your perfectly normal RDBMS that of course you're using with your project (my point here is, in a production thing you're using a real database), you have a table to store credential ID, public key, authData flags, etc... for a registered credential, and include the corresponding internal user ID that you'll otherwise reference when a user is logged in. Then you index the credentialID field in your credentials table, search that table by credentialID to get the record when a WebAuthn response comes in, use the public key to verify the response, then log the user in as the user ID from that same record after a successful response verification.

Hope that all helps.

[teolag]

Thank you @MasterKale for this really good answer! In my little project I'm writing right now I use a Mongo database and plan to save a collection of authenticatorDevices on each user. But the summary is that I need to use the credentialID to lookup the user. And maybe that is not a problem. In my mind I thought I could get hold of the users username or something first to narrow down the search to a single user first. But when I think about it now it is easier to just use the credentialID and make sure it is indexed properly.

One other thing that I not could figure out was how to save the challenge between the auth registration and verification. But I see now that they adress this issue in the link you suggested.

Thanks a lot!