Unify sign-in and sign-in page to single input for passwordless "code" login

[eensander]

Hi,

We're looking to integrate Ory Kratos (and Hydra) in our app, as a replacement of our current OTP authentication flow using Supabase Auth. With our current setup, there is only a single authentication page (called "login") with a single input for the users' email. Whether the user already has an account or not: the user will receive an email that either registers or logs the user in. It would be very useful if this flow could be recreated in Ory Kratos.

The user flow could look like this:

1. User lands on authentication page,
2. User submits their email-address,
3. An input appears for the OTP-code,
4. If an account for that email-address does already exist:
   • 4.1. User gets a "magic code" email with the OTP-code,
   • 4.2. After the user submits the code, they are signed in
5. If an account for that email-address does not already exist:
   • 5.1. User gets an email with a code, which could be considered to be a verification and OTP code at the same time,
   • 5.2. After user submits that code, their account is created and verified,
   • 5.3. The user is automatically logged in

Note:

• Step 4 is already essentially possible with Ory Kratos, using the "code" method.
• Step 5 is also technically possible, by configuring the the registration hook with session:
  • selfservice: after: code: hooks: - hook: session

To rephrase:
The question is whether it is currently possible to configure Ory Kratos to provide a single authentication page that facilitates both sign-in and sign-up, after the user submits their email-address.

[vinckr]

Hey @eensander
this should be possible using a custom UI - I guess you only want to offer the code option as authentication method?

From the top of my head I would say you have to create a custom UI that:

• Initially only shows an email input field.
• After email submission, checks if the email exists (you might need to implement this check in your backend).
• Based on the existence of the email, triggers either the login or registration flow with Kratos.
• Shows the OTP input field and handles the submission.

Personally I think you should also offer at least the password option and potentially also social login for the best UX - but of course that is a different discussion.

[eensander]

Hi @vinckr, thanks for your reply.

I take it that when you're talking about custom UI, you're talking about this: fork- and adjusting the kratos-selfservice-ui-node repo to our needs. If it's not possible to implement our desired flow solely by adjusting the configuration file, we will consider this route. Thanks.

Also, thanks for sharing your thoughts on UX. I think that there is friction in both passwords and magic codes, but that passwords are more vulnerable - for example when reused, compromised, or predictable. Magic codes are at least as secure as passwords since both rely on the security of the email account. However, password-based authentication fails if either the password or email account is compromised, whereas magic codes fail only if email is compromised. From a UX perspective, I think that entering a 6-digit code from an email is similar in friction to using and copying from a password manager. I also agree with your point on social login, though.

[vinckr]

Hello @eensander

I take it that when you're talking about custom UI, you're talking about this: fork- and adjusting the kratos-selfservice-ui-node repo to our needs.

You don't need to fork the UI, you can also use the Ory APIs and write your own code - but you can of course fork the UI.
See here for some more documentation on how to build a custom UI: https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration

Agreed on the password vulnerability - one way to mitigate this is to use "breached password detection". If you combine that with MFA its actually very solid. Of course depends on the threat model if that makes sense in your use case.

[eensander]

Cool, thanks. And good recommendation 👍