Hook to add 2FA options after registration?

[usatony]

Since I'm on a roll with questions and requests today, I think I'll ask one more. :-) Sorry.

Is there a way to have Kratos natively prompt the user to optionally create a 2FA method after a new identity is registered?

I would ideally like the user's registration flow to work like this:

1. User supplies email address and password (the email address is the user's identifier).
2. User verifies email address by submitting the OTP emailed to the address.
3. On successful verification, identity is registered and session cookie is issued.
4. (Before the registration flow ends) User is prompted to optionally set 2FA methods.
5. On completion or skip, user is redirected to my SPA.

I think I can get this done via the UI, but I'd rather not because it may require an aal2 stepup which would be annoying (and I don't want settings to be changed at aal1). I also don't want to deviate too much from the accepted Kratos way of doing things. I'm programming the UI as an SPA that uses no frameworks or libraries but, instead, is written in plain and broadly compatible JavaScript (it's lightning fast, and PageSpeed Insights loves it). I would hate to do something weird that would totally break and require the UI to be reprogrammed when Kratos is updated.

Thanks!

[vinckr]

Hey @usatony

There is no built-in "prompt to set up 2FA" step in the registration flow. 2FA enrollment happens through the settings flow (/self-service/settings).

Your worry about an aal2 step-up for settings is actually less of an issue for newly registered users than you might think. The required_aal: highest_available setting means Kratos only requires the highest AAL the user has configured. For a brand-new user who hasn't yet set up any second factor, their highest available AAL is still aal1, so they can access settings without completing a second factor challenge.

The most Kratos-idiomatic way to achieve your flow would be:

1. Register with email + password → show_verification_ui hook triggers email OTP verification → session hook issues session cookie after verification.
2. After the registration/verification flow completes (via continue_with redirect or return_to), your SPA redirects the user to /self-service/settings with a return_to pointing back to your app.
3. The settings page shows TOTP/WebAuthn/etc. enrollment options; the user can set them up or skip (by navigating away).
4. This is handled at the UI layer, not natively in Kratos, but it follows the accepted Kratos patterns. Since Kratos's settings flow API is stable, this approach shouldn't break on updates any more than any other custom UI integration would.

Let me know what you think.