Let users sign in by receiving a one-time code at their registered email address and typing it back — no password required. The user proves they control the inbox; the platform verifies the code and issues a session.
When to use it
Section titled “When to use it”This recipe is a good fit for any product where password management is more friction than it is worth. Newsletters, community platforms, internal tools, and mobile-first products often fall into this category. When the user base is not technical, password reuse and forgotten passwords generate a disproportionate share of support tickets. An email-code flow removes that friction entirely.
The tradeoff is that sign-in security is now bounded by email account security. If an attacker can read the user's inbox, they can sign in as that user. For products with sensitive data or significant financial exposure, consider pairing this flow with a second factor or reserving it only for lower-privilege accounts. For lightweight consumer products the tradeoff is usually acceptable, and the reduced friction often improves conversion.
What you will build
Section titled “What you will build”A modified Login flow that replaces the password check with an email OTP sequence. The flow uses three built-in blocks — no custom action is required:
- Look Up Identity — find the user by email and confirm they exist.
- Send Channel OTP — dispatch a one-time code to the user's registered email channel.
- Verify Channel OTP — accept the code the user types back and confirm it matches.
- Issue Session — mint a session for the verified user.
No JavaScript is needed. This is a pure block composition.
Configure it
Section titled “Configure it”Step 1 — Open the Login flow
Section titled “Step 1 — Open the Login flow”Navigate to Flows and click Login. Click Edit to open the flow editor.
Step 2 — Remove or bypass the Verify Password block
Section titled “Step 2 — Remove or bypass the Verify Password block”In the default Login flow, the Pre-Login stage contains an Identity Lookup block followed by a Verify Password block. For a passwordless flow you do not need the password check.
Drag the Verify Password block out of the stage and delete it. If you want to keep a password fallback path, use a Decision block to route users who have a password enrolled through Verify Password and route all other users through the OTP path — but for a clean passwordless-only flow, removing it is simpler.
Step 3 — Add Send Channel OTP
Section titled “Step 3 — Add Send Channel OTP”In the Pre-Login stage, drag a Send Channel OTP block from the block palette and place it after the Identity Lookup block.
In the block's configuration panel:
- Channel:
email - Leave the factor type and other settings at their defaults.
The block will dispatch a code to the email address registered on the user's identity. It writes the masked recipient address and expiry time to state so the UI can display them.
Click Save on the block.
Step 4 — Add Verify Channel OTP
Section titled “Step 4 — Add Verify Channel OTP”Drag a Verify Channel OTP block into the Pre-Login stage immediately after Send Channel OTP.
The block reads the code the user types into the login form and verifies it against the one dispatched in the previous step. No additional configuration is required — the block finds the active OTP via the user_id resolved by Identity Lookup.
Click Save on the block.
Step 5 — Confirm the Issue Session block is present
Section titled “Step 5 — Confirm the Issue Session block is present”The Post-Login stage should already contain an Issue Session block. Confirm it is present. If the stage is empty, drag an Issue Session block in from the block palette.
The completed flow has this shape:
Login flow Stage: Pre-Login Look Up Identity (must_exist: true) Send Channel OTP (channel: email) Verify Channel OTP Stage: Post-Login Issue SessionStep 6 — Confirm the email channel is configured
Section titled “Step 6 — Confirm the email channel is configured”Before publishing, verify that your tenant's email channel is set up. Navigate to Branding → Email Settings and confirm a sending address and an SMTP connection (or platform-managed mailer) is active. The Send Channel OTP block relies on this channel to deliver the code. A flow that uses this block with no email channel configured will fail silently at delivery time — the block is fail-open, meaning it passes the flow even when delivery fails.
Step 7 — Publish the flow
Section titled “Step 7 — Publish the flow”Click Publish in the flow editor toolbar. The change is live for the next login attempt.
This recipe modifies the system Login flow in place. All users who log in through this tenant will use the OTP path after you publish. If you want to offer password login alongside OTP login, use a Decision block to branch on whether the user has a password credential enrolled, rather than removing Verify Password outright.
Test it
Section titled “Test it”Navigate to Flows → Login → Test in the admin console.
In the Event JSON editor, set user.email to the email address of a test account that has a registered email channel. Click Run to simulate a login start.
The test pane will show the Send Channel OTP block in the execution trace. Because test runs do not deliver real emails, look for the block's output in the state viewer — specifically step.<your-block-slug>.masked_recipient and step.<your-block-slug>.expires_at. If those fields appear with values, the dispatch step executed correctly.
To test the verify step, enter the test OTP code shown in the test pane's state output into the Verify Channel OTP block's test input and run again. Expect step.<verify-slug> to show verified: true in the state output.
For the most reliable test, trigger the full flow from the tenant's live login page (see Verify on a live flow below).
Verify on a live flow
Section titled “Verify on a live flow”Navigate to your tenant's login URL — https://<tenant>-<org>.intelliauth.local/login or your production equivalent.
Enter the email address of a test account and submit the form. The login UI should transition to a code-entry screen. Check the inbox for the test account. A one-time code should arrive within a few seconds.
Enter the code in the login UI and submit. You should be signed in. Navigate to Flows → Login → Recent Runs in the admin console and confirm the most recent run shows status Completed, with Send Channel OTP and Verify Channel OTP both in the block execution trace.
If the code never arrives, check Branding → Email Settings to confirm the mailer is active, and check the Audit log for any Send Channel OTP delivery errors.
Cautions
Section titled “Cautions”Anti-enumeration discipline. When a user submits an email address that is not registered, Identity Lookup with must_exist: true denies the flow. The response shape your UI shows for an unknown email should be identical to the response for an invalid code — for example, "We could not verify that email address." A response that says "no account found for this email" tells an attacker exactly which addresses are registered with your tenant.
Email deliverability is the primary failure mode. An OTP flow has no fallback if the user does not receive the email. Before relying on this in production, confirm your email channel is configured and tested. Send a test email from Branding → Email Settings and confirm it arrives in your inbox with no spam-folder placement. Monitor delivery failures through the Audit log — Send Channel OTP is fail-open, which means delivery failures are silent at the flow level.
Code TTLs balance security against usability. A short TTL (5–15 minutes) limits the window an attacker has if they intercept a code. A very short TTL (under 3 minutes) may expire before a user on a slow email connection receives the message. The platform's default TTL for channel OTP codes is visible in the Send Channel OTP block's configuration panel — adjust it to match your users' typical email latency.
Email account takeover is the residual risk. A one-time code proves access to the inbox, not exclusive control of the identity. If a user's email account is compromised, their platform account is compromised too. For accounts with elevated permissions or access to sensitive data, pair this flow with a second factor or consider whether a password-based flow with MFA is more appropriate for that user segment.
The fail-open behaviour of Send Channel OTP requires monitoring. The Send Channel OTP block continues the flow even when delivery fails. This means a login attempt appears to succeed from the flow engine's perspective even if the code was never delivered. In practice the Verify Channel OTP block will deny the user when they cannot provide a code, but the experience is confusing. Monitor delivery errors in the Audit log during rollout.