Magic-link auth for client portals: skip the password

The single biggest reason client portals fail to get adopted isn't price or features. It's the password.

The client gets an email saying "your portal is ready, click here to set up your account." They click. They land on a form asking for a strong password. They invent something. They never write it down. Three weeks later, the firm sends them a file via the portal. They click the email, can't remember the password, hit "forgot password," lose the email in their spam folder, give up, and ask the firm to send the file by email instead.

Multiply that by 50 clients and the portal is dead.

Magic-link authentication solves this. This article explains how it works, why it's the right default for client-facing portals, and the cases where it's not the right answer.

How magic-link auth actually works

A magic link is a single-use URL the firm emails to the client. Click the link, you're logged in. No password.

Mechanically:

1. The firm invites a client. The portal generates a random token (typically 32 bytes of secure randomness encoded as base64url) and hashes it with SHA-256 before storing the hash in the database.
2. The unhashed token is included in a URL like https://portal.firm.com/portal/AbC123... and emailed to the client via a transactional email service (Resend, Postmark, SendGrid).
3. The client clicks the link. The server hashes the token from the URL, looks up the matching hash in the database, finds the associated client and matter, and creates a signed session cookie.
4. The client lands inside their portal, authenticated.
5. The token is invalidated. A second click of the same URL hits a "this link has been used" page.

The session cookie is HttpOnly, Secure, SameSite=Lax, and signed with HMAC-SHA256. Typical session lifetime is 7-30 days, after which the client gets a new magic link by email. No password to remember, no password to lose, no password to be phished.

Why it's the right default for client portals

Most password-based authentication is built for users who use the system multiple times a week. Banking, email, work tools. The friction of remembering a password amortises across thousands of logins.

Client-portal usage doesn't look like that. A typical accounting client opens their portal three times a year: once to upload documents, once to review the draft return, once to pay the invoice. A legal client opens their portal maybe ten times across a six-month matter. An agency client opens it twice in eight weeks.

For these usage patterns, password friction is high-cost-per-use. The magic-link friction (open the email, click) is closer to the underlying experience the client is already doing.

There are five concrete advantages:

1. No password-reset support burden. Most portal helpdesks get more password-reset tickets than feature questions. Magic links eliminate the entire category.

2. Stronger security baseline. The average user picks a 6-character password used elsewhere. A 32-byte random token has 256 bits of entropy. Magic links are mathematically stronger than what most users would pick.

3. No credential stuffing risk. When the next big password breach happens, your clients' passwords aren't on it because they don't have one with you.

4. Adoption rate rises. Practices that switch from password to magic-link auth typically see portal-adoption rates go from 60-70% to 90-97% in the first two weeks.

5. Easier for older or non-tech clients. "Click the link in your email" is universally understood. "Create a strong password" is not.

The objections people raise (and the honest answers)

"What if someone gets access to the client's email inbox?"

If an attacker has access to the client's email, they have access to every other system the client uses that allows password reset by email, which is approximately every system. Magic-link auth isn't worse than password auth in this scenario; it's exactly the same.

The defensive layer is short link lifetime (typically 24 hours for invite links, 15 minutes for sign-in-by-email links) and one-time use tokens. The window for an attacker is small.

"What if the email is forwarded?"

Use short-lived, one-time tokens. If the email gets forwarded after the original recipient clicks the link, the link is dead. If the forwarded copy is opened before the original recipient clicks, the original recipient sees "this link has been used" and the forwarder is in (the same risk exists with password reset).

For matters that require strict identity confirmation (e.g., signing an engagement letter), pair the magic link with a second factor: a one-time code shown on the portal that the client confirms to the firm by phone. This is the layer Marchetti Avvocati uses for first-time logins on commercial matters above €25K.

"What about clients who lose access to their email?"

Magic-link tokens get reissued on demand. The firm sends a fresh link. If the client lost access to the email AND can't be reached by phone, you have a bigger problem than the auth mechanism.

"Doesn't this train clients to click links in emails?"

This is a real concern. Mitigations:

• Send invite emails from a consistent, branded address (noreply@firmname.com, not noreply@some-saas.com)
• Use a custom domain for the portal URL (portal.firmname.com, not firmname.somesaas.com)
• In the email, name the matter and the partner who's expecting the client
• Provide a manual login alternative: "If you didn't expect this email, visit portal.firmname.com and log in by entering your email"

The combination of branded sender + branded URL + named matter context makes the magic-link email distinguishable from phishing.

Where magic-link auth is NOT appropriate

Magic links don't work for every context. The cases where you need password auth:

1. High-frequency users. Your firm's own staff (partners, paralegals) are inside the portal multiple times a day. They get real accounts with passwords and 2FA. Magic links are for the client side only.

2. Compliance regimes requiring "something you know" + "something you have." Some regulated workflows (medical records, banking, certain government services) require multi-factor with a password component. Magic links count as "something you have" (email access) but not "something you know."

3. Shared portal access among multiple client-side users. If five people at the client need access and they trade off, the magic-link-per-email model produces five separate session histories. For shared mailboxes (common in finance teams), password auth is cleaner.

4. Air-gapped clients. If the client's organisation blocks external email, the magic link never arrives. You need a manual session-creation workflow (an admin at the firm logs the client in via a temporary code shared by phone).

For the vast majority of small-firm client-portal use cases, none of these apply.

What the implementation looks like

A defensible magic-link implementation has these properties:

• Tokens are cryptographically random (e.g., crypto.randomBytes(32) in Node, not Math.random())
• Tokens are SHA-256 hashed at rest in the database; only the hash is stored
• Tokens have a TTL (24 hours for invitations, 15 minutes for re-login)
• Tokens are one-time use (consumed on first click, with a clear "already used" page for subsequent attempts)
• Rate limiting on token-generation endpoints (max 5 invite links per hour per source IP)
• Logging: every token issue and every token consumption gets logged with timestamp, IP, and user-agent
• HTTPS-only, HttpOnly, Secure, SameSite=Lax cookies for the resulting session
• HMAC-signed session cookies with a server-side secret
• Audit log in the portal showing the client when their portal was last accessed, from where, on what device

If a portal vendor can't describe their implementation in these terms, that's a reason to ask harder questions before buying.

What this looks like in ClientNest365

ClientNest365 uses magic links as the default for client invites. The token format is 32 bytes of base64url-encoded randomness; the database stores SHA-256 hashes only; tokens expire in 24 hours and are one-time use. The session cookie uses HMAC-SHA256 signing with a server-side secret stored in the workspace environment.

Firm staff (the workspace owner, paralegals, designers) authenticate with password + Supabase Auth, with optional 2FA. Magic links are not available for the firm side; the daily-driver use case there needs proper account management.

If you want to see how the invite flow looks in practice, the agency walkthrough, accounting walkthrough, and law-firm walkthrough all show the client-side experience with real screenshots.

The summary: passwords are for software your users open every day. Magic links are for software your users open three times a year. Pick the auth model that matches the actual use.