Passwordless Authentication: What It Fixes and Costs

The client portal did not need registration, a password policy or a forgotten-password queue, because it needed a person at a property customer to open an invoice, download a report and see only their organisation's records.

I built it with an email one-time passcode: enter an address, receive a code through Postmark, enter it in the same browser, then get a session scoped to that client's properties, inspections, reports and invoices.

The platform holds more than 25,000 properties, more than 60,000 inspections and over 17 million attachments, yet portal users have an invoice to check or a report to send on perhaps twice a year, so I would not make them choose and remember a password first.

Authentication is the first product flow, and if it asks for effort before providing value, it has to earn that effort, which passwords rarely do.

A portal login should match the job the person came to do

The old invoice surface used a shared access-code session before redirecting a person to retrieve an invoice, which was a tolerable shortcut but not once the portal carried reports, property history and documents that should not be available to anyone with a code passed through an email thread.

The replacement needed an identity tied to a client relationship, because proving somebody controls [email protected] proves mailbox access, not which records they may read - an email address is not an authorisation model.

The flow verifies an address with a one-time passcode, resolves it to a portal user and scopes the session to that user's client, so a user can see assigned properties, inspection history, reports, invoice PDFs and ZIP bundles for that client; records are scoped when loaded, not behind a broad query endpoint and a filter dropdown that merely hides other clients.

Permissions become expensive when they arrive late, because a private-looking interface is insufficient: the server must reject another client's document, links are copied, tabs stay open and someone eventually changes a URL by hand.

Every product needs to distinguish login from permission, as I learned on a fostering-sector platform where carers, administrators and super-administrators were separate, ordinary administrators were limited to their teams, and public sharing routes had independently managed slugs that could be deactivated; the public page was intentionally narrow because the information needed care. Most products do not need that role structure, but passwordless login cannot repair vague access rules.

Ask: after authentication, what exact row, document or action becomes available? “Whatever their account can see” means the model is not decided.

Passwords add work before they add trust

A password requires a new user to create, store and reproduce a secret, while the application needs hashing, reset email and token expiry, password-change screens, lockout behaviour, breach-monitoring decisions and support for someone who loses their email and password together - that can be right work, but it is not free.

For a client portal, work email is already associated with a client record and is a familiar recovery channel, so six months later there is no old password to guess three times before lockout; the conversion gain is ordinary: fewer decisions and duplicate inputs.

A common bad flow asks whether to sign in or sign up, then for email, password and confirmation, sends a verification email, and returns the person to sign in with the password they made two minutes earlier, although a returned one-time credential is enough evidence to create a session - sending them back to login is usually a product mistake.

Passwordless does not mean automatic account creation: this portal requires an address that resolves to a user with portal access, keeping onboarding under the agency's control, while the organisation that owns the data sets up the relationship and the user does not perform a separate ceremony to access it.

There is no password database for this product to store or password-reuse problem to inherit, but that does not secure an account by magic: the boundary shifts to the mailbox, code lifetime, session handling, rate limits, user-enumeration behaviour and address-to-permission mapping, which is a better trade for many portals.

Email delivery becomes part of the login system

Email is now the critical path, since a delayed, filtered or rejected message blocks login, whereas with passwords email is usually recovery.

The email must be transactional, recognisable and sent from an expected domain with clear expiry, and resends need defined behaviour: a team must distinguish a mistyped address from delivery failure, because a resend button alone can create five valid codes and a confused person trying each, so decide whether resending invalidates the prior code, its lifetime and request frequency, then test the unhappy path.

Postmark is a delivery dependency, not a detail to hide from operations, so its credentials and sender configuration must work, the provider must be monitored, and support needs enough information to help without reading the code.

“We cannot find that address” lets an attacker discover customer members, while a neutral acknowledgement avoids disclosure but is less direct for support; on a public portal, I would use the neutral response, carefully record failed requests internally and give administrators a controlled way to check whether a portal user exists.

Rate limiting is essential because passcode requests can annoy an inbox, probe address lists or run up email costs, while unlimited verification can guess short codes; a code needs enough entropy, a short life, a request limit per address and IP, and a cap on failed attempts, while thresholds depend on traffic and risk but are required.

When the mail provider is down, new email-only logins wait while existing sessions may continue according to their lifetime, but users without one are blocked; for reports and invoices that can be acceptable with dependable delivery, sensible sessions and a support route. Emergency access or a high-value financial action warrants another recovery method - hardware-backed authentication, support-assisted identity, or a password with a stronger second factor - because the product, not fashion, selects the method.

A magic link is simpler on paper and worse in some browsers

Magic links and one-time passcodes both prove the person can receive email at an address, but fail differently: a link is excellent when email and browser are together - one laptop click, no code to copy or transpose - and is reasonable for a low-risk desktop product.

Mobile changes this: a person can request a link in one browser, open mail and consume it in the mail app's browser or another profile, authenticate elsewhere, return to the original browser and see login again, which is not rare enough to call user error.

A passcode keeps the original session, so the person reads a notification, returns, enters the code and finishes in the intended context, while modern mobile operating systems may fill it; the extra input avoids brittle cross-app handoff.

This portal uses email OTP rather than a magic link because it will be opened from a report or invoice email, on a phone as often as at a desk, and keeping the initial browser session is worth an extra field.

A link is a bearer credential, and a forwarded “View report” button can look like an ordinary document link, while a forwarded short-lived code has the same property but makes sharing more visible, and neither solves shared inboxes. Several people can use a normal finance@ or property@ mailbox, so if a product needs person-level audit history, approval rights or reliable offboarding, require named users, individual access and client-managed membership; if the business wants shared access, describe it as shared, restrict its capabilities and do not claim person-level accountability.

Short link expiry reduces the time a forwarded or intercepted credential works, but fails for someone on a slow connection, in a crowded inbox or returning after a meeting, so make expiry clear, offer a simple reissue path and decide before launch what support can do when the address is unavailable; do not make a link permanent for a clean demo.

Passwords are still correct in some products

Passwords are correct when a product needs an independent credential rather than mailbox availability, such as for staff without personal email during a shift, accounts with formal recovery checks, or frequently used long-lived accounts across controlled devices.

Passwords can also support stronger authentication: an administrator who exports sensitive records, changes payment details or manages others' access may need a password plus a time-based authenticator, passkey or managed-device policy, and on the fostering-sector platform, enabled administrator accounts had separate two-factor gates because they managed profiles and controlled sharing, with team membership also limiting access, so the factor should match what a compromised account can do.

Passkeys deserve serious consideration for many consumer products because they avoid passwords and can resist phishing better than email credentials, although they still require recovery, device-change handling and a decision for users without a compatible or enrolled device.

For an internal tool behind single sign-on, use the organisation's identity provider rather than build a separate password estate when it already centralises offboarding and password policy.

For an occasional-access external portal, email OTP remains a good default when documents are client-scoped, the portal-user list is managed, delivery is watched and the limits are explicit.

Authentication is a product boundary, not a component to tick off

Serious auth needs invitation or account creation, credential generation and expiry, session rotation, sign-out, login throttling, permission checks, audit events and recovery, so test that one client's user cannot fetch another client's PDF and decide what staff do when an email address changes.

The first-run path must not turn an email typo into a new client account, a user removed from a client must lose future access, and a copied document URL must not become public - these are normal cases.

In the property platform, invoice PDFs are retrieved through the agency's authenticated Xero connection and served by application endpoints, not through a raw Xero URL; the portal identifies the requester, finds the invoice through the client relationship, then serves the authorised document, and I trust that more than a link that works until it is forwarded.

The system records operational state, integration events and audit data because private access is operational work, not a decorative login screen, while keeping authentication in the Rails application keeps portal rules beside protected data instead of across a third-party dashboard and browser code.

When reviewing a build quote, ask for the path from emailed credential to record, how a removed employee loses access, what the audit trail proves after a report download, and whether identity is distinguished from permission, because those questions reveal more than a polished sign-in page.

I build client portals where login and permissions are designed together, and for the rest of the work behind that boundary, see my CV and rates, while for the Rails choices that keep a portal like this small and operable, read my Rails stack.