CODEWITHSUNDEEP
touch-idwebauthnface-idfidowindows-hello
mackie
mackie

Reputation: 5264

Enrollment strategies for FIDO2/WebAuthn when using built in authenticators

This is more of a philosophical question rather than a technical one but I think it's still relevant even if it boils down more to UX design than anything else.

It's 2021, hardly anyone has a Yubikey or similar but nearly everyone has a phone, tablet or desktop/laptop with a TPM and an OS or browser that supports FIDO2 & WebAuthn. Therefore I'd like to explore ways to make the built-in authenticator enrollment process as slick as possible and not require them to have conventional password auth in place (at least temporarily) to allow it to be done.

Is anyone aware of an approach out in the wild similar to the OpenID Connect device flow whereby someone could go to a public enrollment endpoint, do the enrollment ceremony for their device and then use a resulting unique code to link it to an account on another already enrolled device?

I'd see it working something like this:

  1. User visits https://idp.mycompany.com/enroll via link or some instructions
  2. They hit the "enroll this device" button and trigger the create credential interaction (would likely need to prompt for the user ID here as we'd need it to set up the resident key)
  3. We store the resulting credential in the backend and exchange for a unique code (e.g. ABC123)
  4. User visits https://idp.mycompany.com/enroll/ABC123 on an already enrolled device (or possibly accesses an UI where the code can just be typed in)
  5. User is prompted to authenticate using the resident key on their already enrolled device
  6. Once the user is signed in the stored credential is added to the user account in question and they receive a visual confirmation
  7. User is able to sign in using the credential on their newly enrolled device

This feels to me to be pretty secure as even if a code could be guessed the worst you could do would be to add someone else's credential to your account and since this is happening in an authenticated context we can implement rate limiting easily. The user would be free to manage their credentials after the fact however they see fit via a management UI.

Step 2 is probably the bit that's least clear for me but my thinking is that it doesn't really matter if the user provides garbage user details for the resident key as we'll be linking based on the credential ID in the backend anyway. If they put nonsense in then they're just impacting their own UX and nothing else and will be free to correct the mistake if they wish.

Thoughts?

Addendum: Having pondered it some more I think this approach (and the OIDC/OAuth2 device flows for that matter) open up a significant phishing vector and thus should probably be avoided.

Upvotes: 1

Views: 506

Answers (1)

Ackermann Yuriy
Ackermann Yuriy

Reputation: 617

General flow is such:

  • Service enables "Login passwordless" feature.
  • Next time user logs in, service checks if platform authenticator is available, and if it is, user will be prompted with "Would you like to enable passwordless login?".
  • If user agrees, the service then registers device credential(with RK is required).
  • During the login, user may choose to use username, in which case the service will try available FIDO credentials.
  • Or, user may press "Login usernameless", and then go through the RK process.

There is certainly no need in codes.

BTW: FIDO Alliance has it's own UX/UI guide, called "How to FIDO" https://github.com/fido-alliance/how-to-fido and I would highly recommend to take a look at it.

Upvotes: 2

Related Questions