Which authentication methods does Hanko support?

Updated

Hanko supports password, one-time passcode, and passkey login, plus multi-factor authentication (MFA) with security keys or an authenticator app. Account creation accepts email or Google sign-in. These methods are delivered as embeddable UI components driven by flow-state actions, so you can pick the combination that matches your app's login requirements.

Login methods

The sign-in flow presents a method selection screen ("Select login method") with three options:

Method How it works What the user does
Password Standard credential login Enters email and password
Passcode One-time code sent to the user's email address Enters the code, with an option to send a new one
Passkey WebAuthn-based authentication Completes the browser/device passkey prompt

The passcode screen shows the expected interaction directly: a passcode input, a continue action, and a "Send new code" fallback. The passkey path is triggered by a WebAuthn request-options action, which is what initiates the device's native passkey ceremony.

Multi-factor authentication

MFA is offered as an additional step after the primary login. The setup screen explains the purpose plainly: it adds a step so that even if a password or email account is compromised, the account stays protected. Two second factors are available:

  • Security keys — hardware-backed WebAuthn credentials
  • Authenticator app — an OTP secret enrolled into a TOTP app

The MFA screen also includes a Skip option, so MFA enrollment is not forced at that point in the flow.

Registration and account creation

The create-account screen asks for an email address and offers a Continue with Google alternative. Existing users are routed to login from the same screen. This means a new user can start with either an email-based flow or a Google account, and the email path then connects to whichever login method they choose.

How these methods are wired into your app

Hanko exposes these flows as components with named actions rather than fixed pages. The evidence shows the pattern:

  • A passcode verification action runs with the entered code: flowstate.actions.verify_passcode.run({ code: passcode })
  • Method selection dispatches to distinct actions, e.g. continue_to_password_login, continue_to_passcode_confirmation, and webauthn_generate_request_options
  • MFA setup dispatches to continue_to_security_key_creation or continue_to_otp_secret_creation, with skip as the opt-out

Because each step is an action, you can present the methods you want and omit the rest, rather than being locked into one login screen.

What this means for your decision

If your requirement is a modern, phishing-resistant login, the passkey and security-key paths cover it. If you need a low-friction option for users without passkeys, passcode and password are available. If you need a second factor for sensitive accounts, MFA with authenticator apps or security keys is supported, and you can leave it optional.

One caveat: the page evidence describes the available methods and their flow actions, but it does not state default policies such as whether MFA can be enforced for all users or how method availability is configured per project. Confirm those specifics against Hanko's documentation before committing to a rollout plan.