Support for Usernameless

[fturiot]

Hello,
has anyone implemented userless webauthn authentication?

thanks for help
regards

[akanass]

It's implemented since PR#97 so all is ready to do it

[fturiot]

yes ok bit for registration i have residentkey
but how i get user information?
registration change ?
thanks

[MasterKale]

@fturiot There's some work going on right now on the SimpleWebAuthn homepage to document how to set up your server to support Usernameless. In the meantime, here are some bits of info that can help:

1. Configure attestation options to require resident key and user verification.

Your options should look something like this:

{
  "user": {
    // By nature of the fact that this is usernameless you'll have to specify 
    // something here, even if it's not pretty
    "name": " (Usernameless user created at 2/1/2021 5:53:46 PM)",
    // Generate an otherwise legitimate user ID here, unique from any other
    // user account in your DB
    "id": "IChVc2VybmFtZWxlc3MgdXNlciBjcmVhdGVkIGF0IDIvMS8yMDIxIDU6NTM6NDYgUE0p"
  },
  "authenticatorSelection": {
    "requireResidentKey": true,
    "userVerification": "required"
  }
  // ...all the other options here...
}

You will need to generate a random value for user.id as usernameless implies that you can't know the user's account ahead of time; essentially, any time a user performs usernameless attestation they'd be creating a new user in your account.

That's not to say you actually create a new user account in your system before they complete attestation verification; rather, you're generating and temporarily persisting a user ID, as part of the generateAttestationOptions() step, that will get applied to the account you create after the user taps their authenticator and your server verifies the response via verifyAttestationResponse().

2. For assertions, don't specify anything for allowCredentials.

Allow any authenticator with a credential for your RP ID to perform login.

3. Reference the user ID that is returned in the assertion response

By nature of the fact that you won't have usernames as part of your system, your server will have to rely on the user ID returned during assertion to know which user is logging into your system. This is the userHandle value in AuthenticatorAssertionResponseJSON (body.response.userHandle) that will be populated in the authenticator's response.

Assuming verifyAssertionResponse() returns true for verified, your server would then establish a session for the user using account information row in your DB with the row ID/userHandle column equal to userHandle.

---

This is all off the top of my head as I haven't sat down yet and tried to implement usernameless myself. There's some good info in this How To FIDO doc the FIDO Alliance is working on that might also help. I don't think they yet cover usernameless but there's still some good info on implementing WebAuthn login for at least 2FA and Passwordless.

[MartinJaskulla]

I am trying to go usernameless on Mac OS and iOS without an external security key. Is this supported?

When I don't specify anything for allowCredentials as per 2. For assertions, don't specify anything for allowCredentials,

startAssertion({
      "challenge": "zJTGJ1yTqtL3l4jkDctTqx_7_Im7r0s7_bgshbmKbw8",
      "timeout": 60000,
      "userVerification": "preferred",
      "rpId": "localhost"
})

I get this error on Chrome:

[patte]

Thanks for the write up.

I spottet the following typo in "Your options should look something like this:"

  "authenticatorSelection": {
    "requireResidentKey": true,
    "userVerification": "required"
  }

Must be the following, due to AttestationOptions.ts#L122.

  "authenticatorSelection": {
      residentKey: "required",
     "userVerification": "required"
  }

Note to myself: use typescript

[MasterKale]

@MartinJaskulla That's a desktop Chrome error modal - after some further testing it seems Chrome just doesn't support usernameless. If you try that same startAssertion() call in Safari on Big Sur you should get this "saved account" modal that lets you choose an account to log in with:

Accounts that show up in this modal are assigned to a resident key because Safari always generates resident key credentials (because as per the WebAuthn spec authenticators are allowed to generate resident keys for generated credentials even if a resident key isn't explicitly required...). Clicking one of these accounts will then submit that credential to the RP, at which point the RP can use the "userHandle" property to identify the user that's logging in. That's the usernameless flow in a nutshell; unfortunately it's not feasible with Chrome.

@patte So technically you can set just "requireResidentKey", as that was the original way to require a "resident key" (redefined to "discoverable credential" in L2) in L1 of the spec. The section of code you called out above forces "requireResidentKey" to true when the new property, "residentKey", was introduced in L2 of the spec and mandated that the older property be set to certain values when "residentKey" is specified.

As for typing, TypeScript won't give you any trouble setting both as per the AuthenticatorSelectionCriteria interface:

export interface AuthenticatorSelectionCriteria {
    authenticatorAttachment?: AuthenticatorAttachment;
    requireResidentKey?: boolean;
    residentKey?: ResidentKeyRequirement;
    userVerification?: UserVerificationRequirement;
}

I'd agree with you, though, that it's better to use "residentKey" going forward.

[MartinJaskulla]

Thanks a lot! Can confirm it works in Safari, but not in Chrome and Firefox.

[shu8]

3. Reference the user ID that is returned in the assertion response

By nature of the fact that you won't have usernames as part of your system, your server will have to rely on the user ID returned during assertion to know which user is logging into your system. This is the userHandle value in AuthenticatorAssertionResponseJSON (body.response.userHandle) that will be populated in the authenticator's response.

Assuming verifyAssertionResponse() returns true for verified, your server would then establish a session for the user using account information row in your DB with the row ID/userHandle column equal to userHandle.

@MasterKale Apologies if this is the wrong place for me to ask a question following on from this (please redirect me if so!).

Thanks a lot for building this, it's really great! I'm struggling with just one part of the usernameless flow, namely how to store the challenge created from generateAuthenticationOptions (server GET) against the user (who we do not know at this point), so that it can be verified via the expectedChallenge in verifyAuthenticationResponse (server POST)?

I think I understand that in verifyAuthenticationResponse (POST), we would use the userHandle to find the Challenge to pass as expectedChallenge, but I think I may be missing something obvious for the step before, to actually save the authentication Challenge against the (unknown) user in the first place!

I'd be really grateful if you had any advice regarding this! :)

(I think my question is similar to #103 (comment) but unfortunately I still couldn't quite figure out what to do here.)

[fturiot]

yes thanks, but user in this form is not accepted in simpleauthn
replace by userId and username ?
i test
thanks for all

[MasterKale]

yes thanks, but user in this form is not accepted in simpleauthn

replace by userId and username ?

Ah, yes, to populate those two fields you would indeed populate userID and username when generating attestation options.

[fturiot]

yes thanks, i go to developp login
thanks for all

[fturiot]

in login key populate user information ?
thanks

[MasterKale]

I'm not sure I understand your question. Can you provide some more context of what you're asking about?

[fturiot]

login passwordless and userless
the user id is send by resident key ?

[MasterKale]

login passwordless and userless
the user id is send by resident key ?

Yes, the value you specify as userID during registration/attestation should be the same value the authenticator returns as response.userHandle during login/assertion.

[fturiot]

ok but i use uuid for id user but problem for decode this
i have by example '6d1eee38-098e-48f5-abad-8e9a8481fac8' id transmit
but i recept mNqPsbV-d2tFtfyaT34TLA

[fturiot]

i think i must be decode

[MasterKale]

Yep, decode that to buffer and it should work for userID.

Also keep in mind user.id is a buffer with a maximum size of 64 bytes. Your UUID is going to be fine, I figured I'd call it out anyway.

[fturiot]

thanks for all just one last question in Verify attestation response the id populate is it userId ? thanks for all regards

…

-- Frédéric TURIOT

[MasterKale]

Unfortunately no, it's the Credential ID. You don't get user.id back in an attestation response, you have to persist it like you do challenge.

[MasterKale]

@fturiot I'm going to convert this into a Discussion since it's turned into a very interesting conversation I don't want getting lost in the Closed Issues section of the repo.

[fturiot]

i have solve to send in header user.id

[akanass]

@MasterKale I just wanted to let you know that I ended up implementing authentication without a password or username and everything is working fine. I will publish my demo app and I could give you the link so you can test. I will also provide my GitHub so you can see the code behind. Thank you for this beautiful bookstore which helped me a lot

[MasterKale]

That's great news, and thank you for the kind words! I'd love to see how you pulled it off when you're comfortable sharing 😄

[timstrasser]

When using resident keys, what "expectedChallenge" would one provide when verifying the assertion response? As username-less implies, we don't know anything about the user that's going to log in, and we can't just use the returned userHandle until we verified the assertion response.

Also, what I don't understand: How can we verify the signature if we don't know the public key?

[timstrasser]

Yes, there's nothing left in there. :/

[akanass]

Sorry I can't do more.

I know it's store there in Brave/Chrome so I don't know where is it for Safari

[timstrasser]

No problem, thanks for the effort anyways. :)

[MasterKale]

Things might be getting better with macOS Monterey https://developer.apple.com/wwdc21/10106 👀

[timstrasser]

Yaaay! This looks very promising!

[guillewu]

Hi all! Very interesting and helpful thread. I was wondering if anyone was able to "combine" register/login?
The issue I'm bumping into is a bit of a UX issue I guess. The problem is that if the user has registered previously, and somehow they forgot they already registered and they go through the register process again, webauthn will just create a new user. Is there a way to somehow check whether there's already a credential related to the domain the user is trying to log in to and offer them to sign in with that first (before creating another user/credential)?

[MasterKale]

Something like this is coming! "Conditional UI" is a proposed addition to WebAuthn L3 that would allow RPs to essentially nudge a user to log in with an existing discoverable credential if one exists, without the user needing to initiate an auth attempt that the RP knows will fail. It's an opportunistic API addition specifically because of how hard it is, for example, to detect when the user has already enrolled their computer's platform authenticator without attempting authentication and falling back to registration if that fails.

In a usernameless context there's still a chance of a user re-registering if they jump onto a new device since usernameless necessarily utilizes an empty allowCredentials array. In that case you'd need to come up with some kind of bootstrapping mechanism and instruct your users on how to use it if they want to log in from multiple machines 😬

Or perhaps it makes you push your users to use discoverable-credential-capable security keys instead 🤔

[JonahStein]

Is there a time table for Conditional UI?

[MasterKale]

Not one any of us using this in production should count on. It'll be an addition to WebAuthn L3 (L2 is the current version) and once L3 gets officially published it then becomes a matter of time for browser vendors to actually implement that functionality.

What's likely to happen is that Chrome and Edge Chromium will likely get initial Conditional UI support before L3 lands (they tend to be on the forefront of practical WebAuthn implementation as far as browsers are concerned, often helping drive definition of the spec), then Safari will probably get it, then if we're lucky Firefox gets on board too.

If I had to guess? We're a six months to a year out from Conditional UI becoming available in Chrome, and you'll still need to implement fallback behavior for other browsers that don't support it yet.