Magic Link Authentication for B2B SaaS: Flow, Risks, and Alternatives

A magic link is a one-time, time-limited URL sent to a person’s email address. Opening it completes a sign-in or verification flow without asking for a password. That can be convenient, but the link depends on the security and availability of the mailbox—and successful sign-in does not decide which customer account or application resource the person may access.

For B2B SaaS, the useful question is not whether magic links are “more secure than passwords” in the abstract. It is whether an email-link flow works with your customers’ mail gateways, devices, SSO requirements and recovery policies.

How does a magic link login work?

The user enters an email address. The authentication service creates a short-lived challenge for that request and sends a URL to the mailbox. When someone opens the URL, the service checks that the challenge is valid and unused, completes the authentication step and establishes the appropriate session. The application still has to validate requests and enforce authorization after login.

A practical implementation has four observable steps:

1. Request: The person submits an email address on the sign-in screen. The response should not reveal whether that address belongs to an account.
2. Delivery: The service emails a unique link with a defined expiry. The user needs a clear “check your email” screen and a safe way to request another link if delivery fails.
3. Redemption: The person opens the link. The service verifies its token and purpose, rejects expired or already-used links, and returns the user to a trusted application URL.
4. Application access: The backend validates the resulting identity context and checks the active tenant, resource owner and permission before returning protected data.

The link should be treated as a sensitive credential while it is valid. OWASP’s URL-token guidance, written for recovery links, is a useful checklist for random, single-use, expiring tokens, trusted URLs, rate limiting and avoiding token leakage. It is not a substitute for testing your provider’s actual sign-in flow.

What can go wrong in a B2B magic-link flow?

An email security scanner opens the link first

Corporate mail systems often visit URLs before a person does. If a one-time link is consumed on that visit, the user sees an invalid-link error despite clicking promptly. Merely extending the expiry does not solve that failure. Test the flow with the mail gateways your customers use, and check whether the provider offers a confirmation step that separates a crawler visit from human redemption.

Frontegg documents an optional link access verification step for this case. It must be enabled; embedded login also has SDK-version prerequisites. An email code can be a fallback when link scanners are common.

The email opens on another device or browser

Someone may request a link on a laptop but read email on a phone. A link can then open a different browser session from the one that initiated sign-in. Some products bind links to the original device or browser for protection; that changes the cross-device experience. Decide what should happen before choosing a default, and test an in-app email browser as well as a normal browser.

An emailed one-time code may be easier to transfer back to the initiating screen. That is a usability trade-off, not proof that a code is safe when the email account itself is compromised.

The link is reused, expires or lands at the wrong destination

A single-use link should fail on a second redemption. An expired link should have an intelligible recovery path rather than a dead end. Check where the user lands after redemption, especially when an invitation names a particular account or application. Do not send a valid user to an arbitrary redirect URL supplied by an untrusted request.

Avoid exposing a raw link token to analytics, logs, browser referrers or third-party scripts. The token is useful only briefly, but during that window it can grant the same entry path as the email recipient.

Email access is mistaken for tenant permission

In a multi-tenant product, the same person may belong to Customer A and Customer B. An email link can establish who controls that mailbox, but it does not by itself prove that the current request is authorized for either customer’s invoice, project or export. The backend must use the authenticated tenant context and enforce resource ownership and action permissions. The authorization architecture guide explains this boundary in more detail.

Also test your customers’ authentication policies. A link should not become an unintended way around a tenant’s required enterprise SSO or MFA flow. Treat login, account invitation and account activation as distinct operations even when all three send an email.

When should you use a link, a code or another method?

Magic links can fit a low-friction sign-in or invitation journey when users reliably receive email, normally open it on the right device, and the resulting session meets the account’s policy. They are less attractive when mail scanners frequently consume URLs or users must switch devices to read email.

Email codes remove the clickable-link handoff and can work better across devices. They still depend on the mailbox and introduce a manual entry step. Enterprise SSO may be the right default when the customer’s identity provider owns workforce sign-in and policy. Passkeys or other phishing-resistant authenticators deserve consideration when the threat model calls for stronger assurance than email access. These choices can coexist, but the allowed path should be explicit for each customer and application.

Do not count an emailed link as an independent second factor merely because it arrives through a different app. NIST SP 800-63B disallows email as an out-of-band authenticator. That rule is about the assurance of an out-of-band factor; it is not a blanket statement that every email-based sign-in flow is forbidden.

How does Frontegg support magic links?

Frontegg offers Magic Link and Magic Code as separate passwordless options in the Login Box. Its current passwordless guide describes one-time links, configurable expiration and email-template settings. The documented default expiration is five minutes, with preset choices from one minute to one hour; choose a value based on the customer experience and risk you actually test, not a universal “best” number.

Frontegg also documents link access verification for scanner-prone email environments and separate user invitation and activation settings. Check the current prerequisites for your hosted or embedded integration. A login method, an invitation method and an application’s authorization policy should not be treated as the same configuration.

What should you test before enabling magic links?

Use a realistic customer account and run these checks before rollout:

1. Request a link for both a known and unknown email. Confirm the screen does not disclose which address exists, and test abuse controls on repeated requests.
2. Open the email through a corporate scanner or link-previewing client. Confirm the person—not the scanner—can complete sign-in, or that an understandable fallback appears.
3. Open the link on the requesting browser, on a phone and inside a mail app. Record which combinations succeed and what the user sees when they do not.
4. Redeem the same link twice, wait for expiry, and request a replacement. Check the failure copy and recovery path.
5. Test a user with two customer memberships, including one account requiring enterprise SSO. Confirm the enabled login method and active tenant are correct for each account.
6. After sign-in, request a resource owned by the other tenant and a list/export containing that tenant’s rows. The application must deny or scope these requests before data is returned.
7. Measure request-to-delivery time, completion rate and invalid-link failures. Break results down by customer mail domain and login method; otherwise a scanner problem can look like general login abandonment.

If the flow passes those tests, a magic link can be a useful part of a B2B login experience. If it fails, the answer may be an email code, SSO, a stronger authenticator or a change to the link-handling flow—not simply a longer expiry. For product fit, see Frontegg authentication; use the developer guides for the exact setup you intend to ship.