feat(elements): Add support for sign in with passkey by panteliselef · Pull Request #3472 · clerk/javascript

panteliselef · 2024-05-30T18:39:34Z

Description

This PR add support for passkey usage within a SignIn flow

APIs introduced:

<SignIn.Passkey />
<SignIn.SupportedStrategy name='passkey'>
<SignIn.Strategy name='passkey'>
<Clerk.Input type='text' passkeyAutofill>

Usage Examples:

<SignIn.Passkey />

<SignIn.Step name='start'>
  <SignIn.Passkey>
    <Clerk.Loading>
      {isLoading => (isLoading ? <Spinner /> : 'Use passkey instead')}. 
    </Clerk.Loading>
  </SignIn.Passkey>
</SignIn.Step>

<SignIn.SupportedStrategy name='passkey'>

<SignIn.SupportedStrategy asChild name='passkey' >
  <Button>use passkey</Button>
</SignIn.SupportedStrategy>

<SignIn.Strategy name='passkey'>

<SignIn.Strategy name='passkey'>
  <p className='text-sm'>
    Welcome back <SignIn.Salutation />!
  </p>

  <CustomSubmit>Continue with Passkey</CustomSubmit>
</SignIn.Strategy>

<Clerk.Input type='text' passkeyAutofill>

<SignIn.Step name='start'>
  <Clerk.Field name='identifier'>
    <Clerk.Label className='sr-only'>Email</Clerk.Label>
    <Clerk.Input passkeyAutofill placeholder='Enter your email address' />
    <Clerk.FieldError />
  </Clerk.Field>
</SignIn.Step/>

Docs PR: clerk/clerk-docs#1132

Checklist

npm test runs as expected.
npm run build runs as expected.
(If applicable) JSDoc comments have been added or updated for any package exports
(If applicable) Documentation has been updated

Type of change

changeset-bot · 2024-05-30T18:39:37Z

🦋 Changeset detected

Latest commit: d16809f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 14 packages

Name	Type
@clerk/elements	Minor
@clerk/clerk-js	Minor
@clerk/shared	Minor
@clerk/chrome-extension	Patch
@clerk/clerk-expo	Patch
@clerk/backend	Patch
@clerk/express	Patch
@clerk/fastify	Patch
@clerk/nextjs	Patch
@clerk/clerk-react	Patch
@clerk/remix	Patch
@clerk/clerk-sdk-node	Patch
@clerk/testing	Patch
@clerk/ui	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

panteliselef · 2024-05-30T18:41:26Z

+        case 'passkey': {
+          return await parent.getSnapshot().context.clerk.client.signIn.authenticateWithPasskey();
+        }


When "Submit" is hit we don't want to call attempt, instead call authenticateWithPasskey

panteliselef · 2024-05-30T18:42:04Z

+  const [isSupported, setIsSupported] = React.useState(false);
+  React.useEffect(() => {
+    async function runAutofillPasskey() {
+      const _isSupported = await isWebAuthnAutofillSupported().catch(() => false);
+      setIsSupported(_isSupported);
+    }
+
+    // @ts-expect-error - Depending on type the props can be different
+    if (passthroughProps?.passkeyAutofill) {
+      runAutofillPasskey();
+    }
+
+    // @ts-expect-error - Depending on type the props can be different
+  }, [passthroughProps?.passkeyAutofill]);


Should this be handled inside an actor ?

Which part are you referring to?

Yeah, passkey specific logic shouldn't live in the common input element like this. Let's try to move it to an actor.

Why does passkeyAutofill need to be on the input?

This is only necessary if we want to support passkey autofill.

Should we rely on "the platform" here? It doesn't feel necessary to create a separate abstraction if all it takes is specifying a native property on the element, unless we need to execute some specific logic to enable autofill.

We also need to call authenticateWithPasskey internally

panteliselef · 2024-05-30T18:55:46Z

+      on: {
+        'AUTHENTICATE.PASSKEY': {
+          guard: not('isExampleMode'),
+          target: 'AttemptingPasskey',
+          reenter: true,
+        },
+        SUBMIT: {
+          guard: not('isExampleMode'),
+          target: 'Attempting',
+          reenter: true,
+        },
+      },


Enabling "autofill" is kind of fire and forget action, so we should be able to recover from this state and not get stuck. Promise will await until user interact with the field and select a passkey and that may never happen.

brkalow

Looking good. I'd like to see the passkey specific logic moved out of the input logic.

brkalow · 2024-06-03T13:47:16Z

+  const [isSupported, setIsSupported] = React.useState(false);
+  React.useEffect(() => {
+    async function runAutofillPasskey() {
+      const _isSupported = await isWebAuthnAutofillSupported().catch(() => false);
+      setIsSupported(_isSupported);
+    }
+
+    // @ts-expect-error - Depending on type the props can be different
+    if (passthroughProps?.passkeyAutofill) {
+      runAutofillPasskey();
+    }
+
+    // @ts-expect-error - Depending on type the props can be different
+  }, [passthroughProps?.passkeyAutofill]);


Yeah, passkey specific logic shouldn't live in the common input element like this. Let's try to move it to an actor.

Why does passkeyAutofill need to be on the input?

brkalow

Looking good. Let's move the logic from the component into useInput() to keep the component layer thin.

Any ideas for not referencing the sign in flow actor directly in the common input components?

brkalow · 2024-06-05T15:23:38Z

+    React.useEffect(() => {
+      if (passkeyAutofillSupported) {
+        signInRouterRef?.send({ type: 'AUTHENTICATE.PASSKEY.AUTOFILL' });
+      }
+    }, [passkeyAutofillSupported, signInRouterRef]);


Can this be in the useInput() hook? Ideally the components here are just thin wrappers around the hook, which contains the business logic

Probably yes, but if felt like something only this component should care about.

because we are using refs here and not the context, it will not error, but i thought it would ok to not litter useInput with sign in specific logic.

Turns out with the current setup this is a bit hard. useSignInPasskeyAutofill will use the useSelector underneath which would error when the SignInRouter context is not available.

brkalow · 2024-06-05T15:24:14Z

  (props: FormInputProps, forwardedRef) => {
    const clerk = useClerk();
+    const passkeyAutofillProp = (props as PasskeyInputProps).passkeyAutofill;
+    const signInRouterRef = SignInRouterCtx.useActorRef(true);


I'm not crazy about referencing the sign in actor directly in these components, but not sure if there's another way. 🤔

Maybe @tmilewski has an idea?

Is this better ?

<SignIn.Passkey> <Clerk.Input /> </SignIn.Passkey>

I can see issues with that as well, because SignIn.Passkey wouldn't know whether it needs to pass the autofill prop or not. To avoid leaking the prop to the dom for everything else, but only pass it to Clerk.Input.

Another thought is to have a SignIn.PasskeyInput, but this does not feel right.

We are now simply detecting autoComplete="webauthn"

brkalow · 2024-06-10T21:50:14Z

+    const field = useInput(props);
+
+    const hasPasskeyAutofillProp = Boolean(field.props.autoComplete?.includes('webauthn'));
+    const allowedTypeForPasskey = (['text', 'email'] as FormInputProps['type'][]).includes(field.props.type);


Should we consider tel here for phone numbers?

I think you are correct

brkalow

👍

clerk-cookie added the elements label May 30, 2024