Guides for passwordless support

[AkanshDivker]

Apologies since this is not exactly an issue, but I was just looking to find out whether there is any estimate on when the additional guides or examples would be created, or if there are any other resources I could be pointed to. I've been trying to get the server portion of the library working to support passwordless but I've been having difficulty figuring it out. Not sure when the notice was added to the docs, so wanted to ask for a clarified update.

Thanks!

[MasterKale]

@AkanshDivker Yeah, it's true I've kinda slept on the whole cookbooks thing. Part of the reason is that a Microsoft colleague and I are trying to make https://passkeys.dev the definitive developers guide on how to implement passkeys, at least from a raw JS perspective (we don't want to be prescriptive about use of any front end dependencies like mine.)

That said, this issue you logged got the wheels turning in my head, and I think I might actually make SimpleWebAuthn more opinionated to encourage adoption of passkeys. That is, I'll change the defaults of some values in the four core @simplewebauthn/server methods to tune output for passkeys use cases, but not remove the ability to override the options so that sites using this lib for, say, second-factor-only can continue to do so.

In the mean time, if you can help me understand what difficulties you've had in trying to get SimpleWebAuthn to work when implementing passkeys, please share them here. Your observations will help me with this effort, including when I document all this on https://simplewebauthn.dev/docs/.

[MasterKale]

Oh yeah, there's currently a page for passkeys support here:

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

Feedback on docs content is always welcome.

[AkanshDivker]

@MasterKale Thanks for your response! I apologize since it seems I completely missed the Passkeys section. At a quick glance, it seems to cover what I want to achieve, which is a completely passwordless solution. Passkey adoption seems to be the correct direction and I definitely feel more push toward that is needed. I'll give the passkey implementation a go and hopefully, I can get a proper understanding of it and get it working as intended.

I'm still relatively new to working with WebAuthn so some things might be a little over my head. There wasn't anything specifically wrong with the server guide, I understood its purpose for using it as 2FA. However, I was unable to grasp how I could properly modify it to support a passwordless only option. I also realized I was ignoring storing the current challenge and checking against it later.

I was a bit confused about generating registration options for a new user. My guess was that a check should be done to determine whether the user already has an account/credentials in the database, and if not, then pass the desired userID and userName into the object passed to generateRegistrationOptions?

Thank you :)

[MasterKale]

I was a bit confused about generating registration options for a new user. My guess was that a check should be done to determine whether the user already has an account/credentials in the database, and if not, then pass the desired userID and userName into the object passed to generateRegistrationOptions?

You shouldn't go full usernameless, the functionality isn't there yet in the spec to update a credential's username after creation if you allow for anonymous account creation, and then let them choose a username afterwards. That means it's highly recommended that you identify the user before you allow any authenticator to be registered.

How you do that is specific to your project, but that's my advice. Do an email confirmation link or something, then when they click the email to confirm their address use that to bootstrap a registration ceremony. At that point you can know a username (their email address), and generate a user ID for them, to use in registration options.

[erickriva]

However, I was unable to grasp how I could properly modify it to support a passwordless only option. I also realized I was ignoring storing the current challenge and checking against it later.

@MasterKale I had this exact same problem when started to learn how to use that. I still have some doubts: which is the best way to store the current challenge? Should it be in a specific DB? Memory-based DB?

[MasterKale]

I had this exact same problem when started to learn how to use that. I still have some doubts: which is the best way to store the current challenge? Should it be in a specific DB? Memory-based DB?

I like using Redis for this because you can setex() the challenge to expire in N minutes, or immediately upon receiving a response and attempt a validation (you only ever want to allow a challenge to be used once, even if the response fails verification.) A session ID in a cookie is an easy way to then pull up the challenge when you get back a response - when you store the challenge in Redis you can use the session ID as its key.

Redis might be considered overkill for this; storing the challenge in a typical DB is also an option. With an RDBMS you'd need to remember to delete the challenge after you get back the response that should have signed it. The technique I described above generally covers how challenges should be handled when working with this stuff.

[AkanshDivker]

You shouldn't go full usernameless, the functionality isn't there yet in the spec to update a credential's username after creation if you allow for anonymous account creation, and then let them choose a username afterwards. That means it's highly recommended that you identify the user before you allow any authenticator to be registered.

How you do that is specific to your project, but that's my advice. Do an email confirmation link or something, then when they click the email to confirm their address use that to bootstrap a registration ceremony. At that point you can know a username (their email address), and generate a user ID for them, to use in registration options.

Thanks for sharing, that sounds like a great idea! Happy to know about any best practices so that I can follow them. I wasn't planning on going usernameless, but I wasn't sure how or when would be the best place to formally assign a username and ID into the registration process. Your suggestion of bootstrapping after email confirmation seems to be the safest way that makes sense.

Thanks again!

[MasterKale]

I think this has turned into a good discussion-like topic, so I'm going to convert this over in case we want to continue this conversation.

[Creekie1337]

The documentation is still a bit rough, especially for the passkeys part. I'm having to cross reference stuff from the main docs in order to implement passkeys in a less than ideal way.

For example; I am looking to implement Passkeys with Conditional UI. This page tells me to look at this page. Then I get really confused and look at the server side implementation of generate auth options, which is this page. Now I'm confused, I'm supposed to know the credential ID? As I'm using conditional UI I have no idea.

Maybe I'm being a bit of a dummy by missing something, but I'm confused.

[Creekie1337]

Perhaps this isn't fully to blame due to the documentation, I see there's multiple issues about this.

[tmountjr]

I think where I'm having a hard time is capturing the appropriate device when using passkey. For example, in Chrome, when I initiate the signin process with an empty array of devices, Chrome asks me to choose which previously-created passkey to use, and then prompts me to use the TouchID on my Macbook to complete the process. But the final stage, verifying that the authentication credential is accurate, fails for me because I don't know what device to pass in the body of my request.

Maybe I'm going about it wrong? I thought perhaps if the browser knew about the passkeys stored on the device, i could skip even the username portion of the user input and get the username instead from the passkey list.

[tmountjr]

I think I got it solved for myself - the problem came down to where i was keeping track of the registered devices. my workflow had me pulling them on the client side and then passing them back to the authentication services, so instead I pulled the user's devices on the server side at the point of validation.

If it helps anyone, the super-slimmed-down version looks like this:

Browser

const opts = await axios.post('/auth/generate-authentication-options', { uid: 'the-user-id' })
const authCredResponse = await startAuthentication(opts)
const verificationResponse = await axios('/auth/verify-authentication', {
  method: 'POST',
  data: {
    currentChallenge: opts.currentChallenge,
    body: authCredResponse,
    uid: 'the-user-id'
  },
  headers: {
    'content-type': 'application/json'
  }
})

Server

// handler for /auth/generate-authentication-options
app.post('/auth/generate-authentication-options', (req, res) => {
  const { uid } = req.body
  const devices = getDeviceListFromFirebase(uid)
  res.json({
    timeout: 60000,
    allowCredentials: devices.map(dev => ({
      id: dev.credentialID,
      type: 'public-key',
      transports: dev.transports
    })),
    userVerification: 'preferred',
    rpID
  })
})

app.post('/auth/verify-authentication', (req, res) => {
  const { uid, currentChallenge, body } = req.body
  const devices = getDeviceListFromFirebase(uid)
  // rest is boilerplate
})

Worth noting that instead of an express server I'm actually running these methods in a serverless lambda and storing state data (like the list of credentials) in a separate Firebase realtime db. The rules are such that the credentials are only accessible to the user that created them, and I'm using the admin SDK to access anything I need from the serverside.