1

I'm currently creating a POC for WebAuthentication and I'm looking at a scenario where we could use cross-platform authenticators as a 2FA method. So essentially: user logs in to their account on the site, and proceeds to register an authenticator for later use.

I'm wondering if there's some way to limit the kind of authenticators a user can use? Like, if I only wanted them to be able to authenticate via BLT (bluetooth) for example? Or if I only wanted them to be able to use Android Passkeys? If there is a way, could someone point me to the documentation of that in the spec (could have missed it) or somewhere else or maybe explain it here?

The reason we might want to do this is to simplify things for the end user, so they don't get a bunch of options that aren't relevant to them. This would help a lot of less tech savvy users actually use this, since the process would be simpler and we might be able to walk them through it step by step a little better. Also, security might want to disallow certain kinds of cross-platform authenticators.

Note: We're just looking at registration for now, not authentication.

If something sounds fishy or doesn't make sense, please let me know and I'll try to clarify.

Charise
  • 55
  • 3

1 Answers1

2

There is a certain degree of control that you have over the modals that appear to an end user when registering a WebAuthn credential. This will depend on your exact meaning of "limit the kind of authenticators a user can use". We can explore this from two angles.

Authenticator Attachment

The first way we can look at this is cross-platform vs platform authenticators. You provide two good examples above for bluetooth and Android passkeys. The bluetooth experience falls under the category of cross-platform (along with security keys). Android passkeys will fall under the realm of platform authenticators.

You can limit the WebAuthn browser modals to explicitly show cross-platform or platform options while excluding the other. This means that as user can click a button "Register Android Passkey", and they will immediately be prompted for the Android experience. Vice versa you can prompt for a cross platform, and only get cross platform options. Keep in mind the modal will show options for BOTH security keys and BLE (this is where you lose some of the control over what appears on the modal).

You can trigger this using the authenticator attachment property in the PublicKeyCreationOptions when registering a new credential.

Here's an example

{
  "publicKey": {
    "rp": {
      "name": "Example Inc",
      "id": "example.com/"
    },
    "user": {
      "name": "user",
      "displayName": "user",
      "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
    },
    "challenge": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
    "pubKeyCredParams": [***],
    "excludeCredentials": [***],
    "authenticatorSelection": {
      "authenticatorAttachment": "platform",
      "residentKey": "preferred",
      "userVerification": "preferred"
    },
    "attestation": "direct",
    "extensions": {}
  }
}

Note the authenticatorAttachment field in authenticatorSelection. Your options are cross-platform and platform for the experience noted above. Excluding the property will allow for both authenticator types.

You can find more information in the authenticator attachment enum section of the WebAuthn spec

The main takeaway for this section - This is mainly for helping the UX, and not overwhelming the user with many options.

Allow/Deny list

The other way to limit the authenticators that can be used in your app is by using the FIDO MDS and Attestation sent by the credential during registration. I have some guidance around this on the Yubico developer website.

In short, if you capture the attestation statement from the registration ceremony, you can compare the results with items in the MDS to determine what specific make/model the authenticator is. If the make/model isn't in your "allowed authenticator" list, then you can reject the registration.

Some notes:

  • It's better to be highly permissive, especially if you have a consumer facing app. You don't want your users confused as to why they can't register
  • You mention passkeys - Google has indicated that copyable passkeys will not send an attestation statement to your relying party, so MDS isn't a great option for limiting passkeys
  • This requires users to always opt into sending an attestation statement. Ensure you have guidance so that your users know to allow attestation to be sent to the RP when prompted in the browser modal

The main takeaway for this section - You can limit authenticators by make/model, but ensure you understand how it affects the UX.

Hope this helps. Feel free to leave a comment if you have additional questions.

Cody Salas
  • 431
  • 1
  • 6