What Is a Magic Link? How Passwordless Client Access Works in Accounting Portals

When a client receives a link to their document portal and opens it in one tap — no username, no password, no “forgot password” loop — they are using a magic link. The name is slightly whimsical for what is, technically, a well-established authentication pattern. But the experience it creates for clients is genuinely remarkable by the standard of how most software asks people to log in.

This guide explains precisely what a magic link is, how it works under the hood, why it is secure, and why it matters specifically in accounting and professional services software — where client adoption is the thing that determines whether a portal actually gets used.

Glossary

Magic link

A magic link is a single-use, time-limited URL containing a cryptographically random authentication token. When a user clicks the link, the server validates the token, establishes a session, and then invalidates the token so it cannot be used again. The link itself is the credential — no password required.

Related: Passwordless authentication, Token-based access, One-time password (OTP)

How a magic link works, step by step

The mechanism is simpler than the name suggests. Here is the full sequence from request to authenticated session.

Magic link authentication flow

The firm generates a request

When you send a client their portal link, the server generates a cryptographically random token — a long, unpredictable string of characters, typically 128–256 bits, produced by a cryptographically secure random number generator. This token is stored in the server’s database alongside the client’s identifier and an expiration timestamp.

The token is embedded in the URL

The token is appended to the portal URL as a query parameter: something like folio.app/portal?token=abc123xyz. This URL is sent to the client via email or SMS. The security of the system depends on two things: the token being unpredictable (hence the cryptographic random generation), and the delivery channel being trusted (the client’s email inbox).

The client taps the link

The client receives the message, taps the link, and is taken directly to their portal. No username prompt. No password field. No “confirm your email address” interstitial.

The server validates and invalidates the token

When the link is clicked, the server looks up the token, confirms it matches a valid entry in its database, confirms it has not expired, and confirms it has not already been used. If all three checks pass, the server creates an authenticated session for the client and immediately deletes or invalidates the token. After this point, the original URL no longer works — clicking it again takes you to an error page, not the portal.

The session continues without re-authentication

Once the magic link is validated, the client is authenticated for their session — typically through a session cookie. If the portal is designed for repeat use (returning clients accessing a portal over several days), the session stays active for a defined window. If it is a one-time submission portal, the session may be short-lived by design.

Why this is secure

The instinct to mistrust passwordless authentication is understandable. Passwords feel like security because they require something you know. But passwords have well-documented failure modes that magic links avoid.

Magic link security vs password-based access

Security property	Password login	Magic link
Phishing resistance	Low — password can be entered on a fake lookalike page	Higher — token is single-use; clicking a phished link yields a used token
Credential stuffing exposure	High — reused passwords across services are the most common breach vector	None — there is no password to stuff or reuse
Brute force resistance	Depends on lockout policy	Impractical — 128-bit random tokens have 3.4 × 10³⁸ possible values
"Forgot password" support burden	Constant — 30–50% of login attempts involve password reset	Zero — no password to forget
Account takeover via credential leak	Common — leaked password databases are actively traded	Not applicable — no persistent password exists
Access after link expiry	N/A — passwords do not expire unless forced	None — expired tokens fail validation, requiring a new link

The key security properties of a magic link are:

Single use. Once a token is validated, it is invalidated. An attacker who intercepts the link after it has already been used gets an error, not access. This differs from a password, which remains valid indefinitely until changed.

Time-limited. Tokens expire. The standard window for client portal magic links is 24 hours to 7 days, depending on the use case. After expiry, the link fails regardless of whether it was used. This limits the window of exposure if a link is intercepted before use.

Cryptographically unpredictable. A 128-bit random token has 2¹²⁸ possible values — approximately 340 undecillion. An attacker trying to guess a valid token by brute force would need to make more attempts than there are atoms in the visible universe before finding a valid one. This is not a practical attack surface.

No persistent secret to steal. With password authentication, compromising a user database can expose millions of credentials simultaneously. Magic link systems store tokens (not passwords) and those tokens expire and invalidate after use — a compromised token database yields only short-lived, single-use values rather than reusable credentials.

Why magic links matter specifically in accounting

The technical explanation above applies to any magic link implementation. What makes it particularly important in accounting and professional services software is a specific problem: client adoption.

Accounting clients are not software users. They interact with a firm’s technology a few times a year, often during their most stressful financial periods (tax season, audit season, year-end). They do not want to manage another password. They do not want to create another account. They are already doing something unfamiliar — gathering financial documents — without the added cognitive load of a login screen they cannot immediately navigate.

How access friction affects client completion rates

~40%

of users abandon account creation flows

Industry average abandonment on first-time account registration, per Baymard Institute UX research.

30–50%

of SaaS login attempts

Proportion involving password reset — per published data from Auth0's 2023 State of Identity report.

<90 sec

median client upload time with magic link access

From link tap to completed submission, Folio operational data, 2026.

When a client receives a magic link, the path from “open the message” to “upload complete” has zero friction points between them. No account creation. No password. No two-factor authentication flow they might not have set up. No browser autofill that fills in the wrong credentials. They tap a link and they are in their checklist.

This is not a minor convenience improvement. It is the difference between a portal that gets used and one that does not.

9 in 10

clients who receive a magic link portal access complete their document submission — compared to significantly lower completion rates for portal systems requiring account creation

Source: Folio operational research, 2026

How magic links compare to other passwordless methods

Magic links are one of several passwordless authentication approaches. Understanding the landscape helps clarify when magic links are the right choice and when another method might be more appropriate.

Passwordless authentication methods compared

Method	How it works	Best for	Limitation
Magic link	Time-limited, single-use token in a URL sent by email or SMS	Client-facing portals — infrequent access, no account management	Requires reliable email delivery; dependent on inbox security
One-time passcode (OTP)	6-digit code sent by SMS or authenticator app	Two-factor verification for existing accounts	Requires client to type a code — more friction than a tap
Passkey / WebAuthn	Device-bound cryptographic key pair, biometric unlock	High-security frequent-use applications	Requires device setup — too complex for infrequent client users
SSO (Google / Microsoft login)	Client authenticates via existing identity provider	Enterprise users who already manage corporate identity	Requires client to have a Google or Microsoft account and be logged in
Time-limited session token	Admin pre-authenticates a session, gives client a URL	One-time access for a specific document set	Less flexible — cannot support return visits or partial submissions

For accounting client portals specifically — where clients access the system a handful of times per year, do not manage the portal themselves, and may not have consistent corporate identity infrastructure — magic links are almost always the right choice. They require the client to have nothing except an email inbox, which every client has.

Common misconceptions

Magic link questions and misconceptions

Is a magic link the same as a shared Google Drive link?

No. A shared Google Drive link is a persistent, unscoped URL that grants access to a folder to anyone who has it — it does not expire, does not limit use to one person, and does not invalidate after first use. A magic link is scoped to a specific recipient, expires after a set time, and is invalidated the moment it is used. The two have completely different security properties.

Can a magic link be forwarded to someone else?

Technically, yes — a magic link is a URL and can be forwarded like any URL. The security consideration is the same as for any email forwarding: if the client forwards the link before using it, the recipient of that forward can access the portal. This is why magic links expire and are single-use — the window of exposure is limited. In practice, the risk of accidental forwarding is very low and is the same risk that exists when a client forwards any email from your firm.

What happens if a magic link expires before the client uses it?

The link becomes invalid — clicking it after expiry returns an error page. The firm (or the portal system) can issue a new link. In a well-designed portal, the reminder emails sent to clients include fresh links rather than the original one, so the client always has a valid, current link available.

Are magic links compliant with the FTC Safeguards Rule?

Magic links satisfy the access control and authentication requirements of the Safeguards Rule when implemented with appropriate token security (cryptographically random, time-limited, single-use) and delivered over a secure channel. They are consistent with the principle of providing the minimum necessary access to each recipient. For full GLBA compliance, the portal system also needs TLS encryption in transit, AES-256 at rest, and a per-document audit trail. See the full guide to FTC Safeguards Rule compliance for accounting firms.

Why do not more software products use magic links if they are simpler and more secure?

Many do — Slack’s email sign-in, Notion’s login flow, Linear, and dozens of other modern SaaS products offer magic links as a primary authentication method. The reason more legacy software does not is that password-based authentication has been the default for 50 years and changing it requires deliberate redesign. Client portal software built recently, with client adoption as a primary design goal, almost universally offers passwordless access. Software built ten or more years ago typically does not.

What to look for when evaluating magic link implementations

If you are evaluating a client portal and the vendor describes their access system as “magic links” or “passwordless access,” these are the specific implementation properties that determine whether it is actually secure.

Magic link implementation quality checklist

• Token length: 128 bits minimum (32+ character hex string or 22+ character Base64URL). Shorter tokens are brute-forceable.
• Token generation: cryptographically secure random number generator (CSPRNG), not a seeded pseudo-random generator.
• Single-use enforcement: the token is invalidated immediately on first use, server-side. Client-side invalidation is not sufficient.
• Expiry enforcement: a token past its expiry timestamp fails validation regardless of whether it was used.
• HTTPS delivery only: the link is sent over a channel where the URL itself is encrypted in transit.
• No token in server logs: the raw token should not appear in server access logs (where it could be extracted by someone with log access).
• Scoped to intended recipient: the token is associated with a specific client record, not just a session.

Folio uses magic links by design, not by feature flag

Every Folio portal link is a cryptographically random, time-limited, single-use token scoped to the specific client. Clients tap once and are in their checklist — no account, no password, no friction. The security model satisfies the access control requirements of the FTC Safeguards Rule.

Review our security implementation