Passkeys Support

[victorbojica]

🚀 Feature

Implementation details

Implemenation docs:
https://docs.google.com/document/d/1G7tO9_dSNi8wur3ajGg4pq-wiHatKDbHv2sBt-uSbQg/edit

TODO

• Should passkeys always be dependent email and password users or have it's own users ?
• Should be a paid feature ?
• Try using same table for challenges
• add indexes on timeout column(s) for querying with cron for removal
• remove schema unused columns (also drop webauth_user_id)
• check counter implementation should work (safari returning 0 everytime)
• timestamps use bigint
• credentials pk should also use app id
• add tenant id only to challenges table
• Confirm Passkeys Support #1046 (comment)
  • From a security point of view, since we allow all fallback methods, passkeys adds no additional security. Is this ok?
  • Should we allow adding passkeys to third party login? Seems strange.
  • Unlike some other providers, we will not allow users to sign up with just a passkey (no password). Is this ok?

[rishabhpoddar]

Suggested flow

Final flow

• Passkeys will be its own login method. Users can type in their email and create a pass key during sign up. This will not require them to add a password.
• We allow passkeys to be enabled alongside any other auth recipe, including third party.
• Passkeys is similar to passwordless recipe in the sense that we have just one sign in / up screen and not separate sign in and sign up screen for it. So this means that if someone enables third party and passkeys only, then it will be one login UI only.
• There will be no extra form fields in this recipe (similar to how we have for passwordless)
• Recovery of passkeys will be via a link (generated by the passkeys recipe) which will allow users to only add a passkey to their account. They will not be able to login or do anything else here other than add a passkey. We have to also take into account that there may be no passkey recipeuserid for this email, and then we will have to also do account linking similar to how its done in reset password API.
• During sign in, if a passkey exists for an email, we use that, and if they cancel out of the flow, we show the other options available to them. The exception here is that if there is third party enabled as well, we show third party options as well along with the email field.
• So whilst we can have two different recipeUserIds for two different tenants (both users have the same email), it can happen that they have the same passkey cause passkeys are tied to origin, and two different tenants can have the same origin.

Older flow (please ignore below)

• Passkeys would be an add on to other auth methods. This means that users would have to set a password if they are using email password login, or do the full magic link / otp flow if passwordless is being used. For third party as well, they would have to go through the third party sign in first.
• During sign up, we would ask users to set a passkey after their first factor login is setup. This can be configurable by the developer if they want to show this or not.
• During sign in:
  • Users would be prompted for their email / phone number first. If social login is enabled, those options will also be shown. So basically this screen: https://master--6571be2867f75556541fde98.chromatic.com/?path=/story/allrecipes-auth--sign-in (if no social login, then it will just be a screen with enter email or phone number). One exception is that if there is only third party recipe configured, we will still show the email box to enable login with passkeys.
  • If they click on social login, then we will only do social login.
  • If they type in an email / phone number, we will see if there exists a user with that email / phone number that has a pass key (across any tenant).
    • If there doesn't exist, we will continue with the usual flow. In case only third party recipe is used, we will show the third party login options.
    • If there exists a passkey, we will prompt the user to login with passkeys and have a button on the UI like "Use another method", which will fallback to as if there is no passkeys.
• During recovery
  - Send a link for adding a passkey to your account

[victorbojica]

Should also think about account recovery (lost device that had passkeys) and the constraints that the passkey usage adds to the flows (such as having email input as a separte step in the log in flow).

[dipeshsingh253]

Hi @victorbojica , @rishabhpoddar

It seems I don’t have access to the implementation document. However, I reviewed the comments from @rishabhpoddar, and the flow is clear to me. I’d love to contribute to this task—could you please assign it to me?

Thanks!