Question regarding code sample

[zoellner]

https://simplewebauthn.dev/docs/packages/server#1-generate-authentication-options mentions in the code example as first step

// (Pseudocode) Retrieve the logged-in user

I have a question regarding that: At time of authentication the user would not be logged in, so what is meant by that?

[MasterKale]

Ah, I can see how that'd be confusing. What I'm trying to point out with that is that you need to identify the user somehow to then be able to populate the allowCredentials value you pass into generateAuthenticationOptions(). True, the user won't technically be logged in yet because this is them attempting to do so. In that case this could be as simple as a username input that the user uses to submit their username, and you then generate options for them to attempt to log in passwordlessly using a previously registered authenticator. If they can, then log them in. If they can't then don't.

I should update that part of the docs 🤔

[seba9999]

Hi ! I was wondering the same as @zoellner ... But I would have pointed to this part of the docs.

// (Pseudocode) Retrieve the user from the database
// after they've logged in
const user: UserModel = getUserFromDB(loggedInUserId);

I mean, ... how could I retrieve a user from the database if ... he is registrating ? O.o

I'm a bit lost in all the WebAuthn process ... What fields are mandatory for my users ? Some unique key ( as email ) ... But if no password ... What should I store ? An Authenticator instance ?

type Authenticator = {
  // SQL: Encode to base64url then store as `TEXT`. Index this column
  credentialID: Buffer;
  // SQL: Store raw bytes as `BYTEA`/`BLOB`/etc...
  credentialPublicKey: Buffer;
  // SQL: Consider `BIGINT` since some authenticators return atomic timestamps as counters
  counter: number;
  // SQL: `VARCHAR(32)` or similar, longest possible value is currently 12 characters
  // Ex: 'singleDevice' | 'multiDevice'
  credentialDeviceType: CredentialDeviceType;
  // SQL: `BOOL` or whatever similar type is supported
  credentialBackedUp: boolean;
  // SQL: `VARCHAR(255)` and store string array as a CSV string
  // Ex: ['usb' | 'ble' | 'nfc' | 'internal']
  transports?: AuthenticatorTransport[];
};

[MasterKale]

I mean, ... how could I retrieve a user from the database if ... he is registrating ? O.o

I must have been thinking primarily about adding authenticators to an existing user. In that case you would easily know the user since they'd have to be logged in to see the page that'd let them register a new authenticator.

In the case of brand-new user onboarding, you'd still need to establish a sense of who the user is before allowing them to register an authenticator. This could mean, for example, using an emailed magic link to bootstrap initial registration. The user clicking the magic link in an sign-up confirmation email would lead to the creation of a new user record on your end, and then you'd associate the subsequent authenticator response to that user when they complete a call of WebAuthn's navigator.credentials.create().

I'm speaking a bit abstract here because the idea is that you still have to establish a "user record" somehow. I used magic links here but another method may be more appropriate for your situation. Then, "Retrieve the user from the database" should still be technically accurate even during first-time user onboarding.

Does this explanation make sense?

[thomasreisinger]

@MasterKale in case I would like to skip e-mail verification and use FIDO2 as registration of a user directly, how do I get to this stage? Should a user be set in the express-session? How do I set the express-session via JavaSciprt on the web browser?

[seba9999]

Does this explanation make sense?

Sorry for the late reply, but yes it does make sense ! Though webAuthn could bypass the password step ( or magical link,... etc steps ).
I've postponed the use of the webAuthn for now to create some password thing ( That I realise I do need in case some device won't support webAuthn ! )

Thanks for you answer :)