Passwordless Login in React: Passkeys, Magic Links and OTP

It's not a secret that passwords are unsafe.

We ask users to invent a secret, remember it for years, never reuse it anywhere else, type it correctly on every device, and somehow keep it safe from attackers.

Then we build password reset flows for when all of that inevitably goes wrong.

Passwordless authentication changes the model. Instead of asking the user for a password, your application can let users authenticate using something like a passkey or a one-time code sent to an email address or a phone.

In this article, we'll take a closer look at the most common passwordless authentication methods, compare how they work and the trade-offs between them. We'll also walk through how you can implement each one in your application.

What passwordless means for a React developer​

For a React developer, passwordless authentication does not mean React suddenly becomes responsible for authenticating users.

Your application still mostly does what it did with password-based authentication:

1. Start the authentication flow.
2. Collect or trigger whatever user interaction is required.
3. Wait for the identity system to verify the user.
4. Receive an authenticated session.
5. Render the application for that user.

The major difference is what credential proves the user's identity.

The three methods you will actually ship​

The most common consumer-facing passwordless options are:

• Passkeys — authenticate using a cryptographic credential stored by a device, credential manager, or hardware security key.
• Magic links — send a short-lived login link to the user's email address.
• One-time passwords (OTP) — send a short-lived code to the user's email address or mobile phone.

We'll look at each of these methods in more detail later in the article.

Where the React app's responsibility starts and ends​

Before we get into the individual passwordless methods, let's get one thing clear: your React application shouldn't be the authority deciding whether a user has successfully authenticated.

In many setups, especially when you use hosted login, React simply starts the authentication flow. The browser moves over to the identity provider, the user completes whatever authentication method is configured there, and once that succeeds, the application gets the result back.

So from React's point of view, the flow is often surprisingly simple:

Start authentication → identity provider handles authentication → continue with an authenticated user

If you build more of the login experience directly into your application, React may do a little more. It might collect an email address, display a code field, or trigger a browser authentication API.

But even then, React is still handling the experience rather than establishing trust.

The actual verification should happen on the server or at the identity provider.

Keep that in mind as we go through passkeys, magic links, and OTPs, because the amount of work your React application needs to do can look very different depending on the method and how you choose to integrate it.

Choosing a method: the comparison nobody publishes​

When choosing a passwordless method, security is only part of the decision. You also need to think about what the login experience looks like when things go wrong, and what it costs to operate at scale.

Some useful questions to ask are:

• What happens if the user loses access to the device they normally sign in with, or the device is simply unavailable?
• Can the user complete authentication on a different device, or does the method depend on the original one?
• What does each authentication attempt cost, especially if you are sending emails or SMS messages?
• How does account recovery work, and how often will users need help from your support team?

These practical questions are sometimes overlooked in favor of security. And yes, security is important, but so is the experience you are creating for the user.

The best choice is usually the one that gives you the right balance between security, usability, recoverability, and cost.

Comparison table​

With those questions in mind, let's compare the most common passwordless authentication methods and see how they stack up.

To summarize:

• Passkeys offer some of the strongest authentication properties of the methods we're looking at. A WebAuthn credential is tied to a specific relying party, and the private key never gets sent to the website during authentication. We'll get into exactly how that works in a bit.
• Magic links and OTP trade some of that security for extremely simple recovery and onboarding.

The recovery question that decides it​

It may sound counter-intuitive, but your recovery model decides which passwordless method you should use in the first place. A very secure primary method does not help much if recovery introduces a much weaker path back into the account.

Suppose you make passkeys the only authentication option.

Then your user:

• loses their phone,
• buys another phone,
• cannot access the original authenticator.

Now you have a recovery problem.

For many users, synced passkeys make this much less painful than early FIDO deployments. Passkeys stored by platforms such as credential managers can become available again when the user signs in to the same provider on a new device. Cross-device authentication can also let a credential on one device authenticate another device.

But eventually you have to deal with the harder case: the user has lost access to every available authenticator, or they can no longer get into the credential provider that holds the passkey.

What do you do then?

If the answer is, "we'll email them a recovery link," then email is part of your authentication security model whether you intended it to be or not.

That's why recovery is not something you bolt onto passwordless authentication later. It's part of the authentication design from the beginning.

That was a lot. But hopefully, you now have a good high-level understanding of what goes into designing a passwordless authentication system. Now let's get into the nitty-gritty and look at how you can actually implement each of these methods in your application.

Passkeys and WebAuthn in React​

We've thrown around the terms Passkeys and WebAuthn a few times so far. Before we go any further, let's properly break down what each one means and how they fit together.

WebAuthn, short for Web Authentication, is the web standard that lets applications authenticate users using public-key cryptography instead of a password. It gives the browser APIs for creating a credential and later using that credential during sign-in.

A Passkey is the credential the user creates and uses through that system.

Users typically approve the use of a passkey using something they already use to unlock their device or credential manager, such as Face ID, Touch ID, Windows Hello, or a device PIN. Passkeys can also be stored on hardware security keys.

Behind the scenes, a passkey is based on a public-private key pair.

The public key is registered with your application. The private key stays with the authenticator and is used when the user later signs in. Your application never needs to receive or store that private key.

Now let's see what that looks like in a React application.

Adding passkeys involves two flows:

• Registration — creating a passkey and associating it with a user.
• Authentication — using that passkey later to sign in.

WebAuthn calls these flows ceremonies.

Let's walk through both flows.

Registration ceremony​

Registration starts when a user wants to create a passkey for their account.

The first step is to ask your server for a set of registration options. You can think of these as the instructions the browser needs to create the new credential.

WebAuthn defines what these options look like, but it does not define the API endpoint you use to retrieve them. In this example, /api/passkeys/register/options is an endpoint we created in our own backend.

const optionsJSON = await fetch("/api/passkeys/register/options", {
  method: "POST",
  credentials: "include",
}).then((res) => res.json());

Here, we assume the user already has a session with the application. credentials: "include" allows cookies, such as that session cookie, to be sent with the request so the server can determine which account is creating the passkey.

The server then generates the registration options and sends them back. A simplified response might look like this:

{
  "challenge": "base64url-encoded-random-value",
  "rp": {
    "name": "My App",
    "id": "example.com"
  },
  "user": {
    "id": "base64url-encoded-user-id",
    "name": "[email protected]",
    "displayName": "Alex"
  },
  "pubKeyCredParams": [
    {
      "type": "public-key",
      "alg": -7
    }
  ],
  "timeout": 60000,
  "attestation": "none"
}

There are a few things going on here.

• rp describes the relying party, which is the website or service the passkey is being created for.
• user identifies the account that the new passkey should belong to.
• pubKeyCredParams tells the authenticator which public-key algorithms the server supports.
• challenge is a fresh random value generated by the server specifically for this registration attempt. When the result eventually comes back, the server checks this challenge to make sure the response belongs to the ceremony it started.

There is one small conversion we need to do before giving these options to WebAuthn.

Values such as challenge and user.id are represented as binary data by the WebAuthn API. Because our server sent them over JSON, they arrive as encoded strings.

The browser provides a helper to convert them back into the format WebAuthn expects:

const options = PublicKeyCredential.parseCreationOptionsFromJSON(optionsJSON);

Now we can actually ask the browser to create the passkey:

const credential = await navigator.credentials.create({
  publicKey: options,
});

From here, the browser takes over the interaction with the authenticator.

Depending on the device and where the user keeps their passkeys, they might be prompted through Touch ID, Face ID, Windows Hello, Android device unlock, a credential manager, or a hardware security key.

Once the user approves the operation, the authenticator creates a new public-private key pair for this credential.

The private key stays with the authenticator.

The browser returns a PublicKeyCredential containing the registration response, which includes the information the server needs to register the corresponding public credential.

React then sends that response back to the server:

await fetch("/api/passkeys/register/verify", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
  },
  credentials: "include",
  body: JSON.stringify(credential.toJSON()),
});

Just like the first endpoint, /api/passkeys/register/verify is an endpoint we implement ourselves.

The server processes the WebAuthn response, checks it against the registration ceremony it started, and extracts the credential information it needs.

If the verification succeeds, it stores the credential ID and public key against the user's account.

At no point does your React application or backend receive the user's fingerprint, Face ID data, or device PIN. Those stay local to the authenticator and are only used to authorize access to the private key.

At this point, registration is complete.

The server has the public credential, the authenticator has the private key, and the user now has a passkey they can use during the authentication ceremony.

Authentication ceremony​

When the user comes back later and wants to sign in, the flow looks very similar to registration.

This time, instead of creating a new credential, we are asking the user to prove that they still have access to a passkey that was registered earlier.

React starts by asking the server for a set of authentication options.

const optionsJSON = await fetch("/api/passkeys/login/options", {
  method: "POST",
  credentials: "include",
}).then((res) => res.json());

Just like the registration endpoint, /api/passkeys/login/options is an endpoint we define in our own backend.

The server creates the options for this specific login attempt and sends them back to the application.

A simplified response might look like this:

{
  "challenge": "base64url-encoded-random-value",
  "rpId": "example.com",
  "allowCredentials": [
    {
      "type": "public-key",
      "id": "base64url-encoded-credential-id"
    }
  ],
  "timeout": 60000,
  "userVerification": "preferred"
}

The shape is a little different from registration because we are no longer creating a credential.

• challenge is another fresh random value generated for this login attempt.
• rpId identifies the relying party the passkey belongs to.
• allowCredentials can tell the browser which registered credentials are allowed for this request. Depending on how you design the login flow, this list may also be omitted so the browser can discover an appropriate passkey itself.
• userVerification tells the browser what level of user verification the relying party is requesting.

As before, some of these values are represented as binary data by WebAuthn, so we convert the JSON response into the format the browser API expects:

const options = PublicKeyCredential.parseRequestOptionsFromJSON(optionsJSON);

Now React can ask the browser to authenticate the user:

const credential = await navigator.credentials.get({
  publicKey: options,
});

At this point, the browser looks for a passkey that matches the request.

The user might be asked to approve its use with Face ID, Touch ID, Windows Hello, a device PIN, or another mechanism supported by the authenticator.

Once approved, the authenticator uses the private key associated with that passkey to create a signed response for this login attempt.

The private key itself never leaves the authenticator.

The browser returns the authentication response to React, and React sends it back to the server:

const result = await fetch("/api/passkeys/login/verify", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
  },
  credentials: "include",
  body: JSON.stringify(credential.toJSON()),
});

/api/passkeys/login/verify is another backend endpoint that we implement ourselves.

The server already has the credential ID and public key that were stored during registration.

It uses that information to verify the response returned by the authenticator.

The server also checks that the response belongs to the challenge it created for this login attempt and that it came from the expected relying party and origin.

If those checks succeed, the server can treat the user as authenticated and continue with whatever comes next in your application, such as creating a session or issuing tokens.

So the authentication ceremony can be reduced to this:

Server creates authentication options
   ↓
React passes them to WebAuthn
   ↓
Browser finds a matching passkey
   ↓
Authenticator signs the challenge
   ↓
React sends the response to the server
   ↓
Server verifies it using the stored public key
   ↓
User is authenticated

If you compare that with registration, the difference is fairly straightforward.

During registration, the authenticator creates a new key pair and the server stores the public credential.

During authentication, the authenticator proves that it still has the corresponding private key, and the server verifies that proof using the public key it already stored.

Conditional UI and autofill​

So far, we've assumed the user clicks a dedicated Sign in with passkey button. That is one way to do it, but passkeys can also be built directly into a normal login form.

Suppose your React application already has an email or username field:

<input
  type="email"
  name="email"
  autoComplete="username webauthn"
  placeholder="Email"
/>

The webauthn value tells the browser that passkeys can be offered through autofill for this field.

Now, instead of waiting for the user to click a separate passkey button, your application can start a WebAuthn request in conditional mode.

First, check whether the browser supports conditional mediation:

const supported = await PublicKeyCredential.isConditionalMediationAvailable();

If it does, ask your backend for the authentication options just like we did in the normal authentication ceremony:

const optionsJSON = await fetch("/api/passkeys/login/options", {
  method: "POST",
}).then((res) => res.json());

const options = PublicKeyCredential.parseRequestOptionsFromJSON(optionsJSON);

Then start the WebAuthn request with mediation: "conditional":

const credential = await navigator.credentials.get({
  publicKey: options,
  mediation: "conditional",
});

The difference is in how the browser presents the authentication flow.

With a normal navigator.credentials.get() call, the browser can immediately show the passkey authentication experience.

With conditional mediation, the request can wait while the user interacts with the login form.

So when the user clicks into the email field, the browser may offer an available passkey alongside the normal autofill suggestions. For example:

[email protected]
Use passkey for [email protected]

If the user selects the passkey, the pending WebAuthn request continues and the browser asks them to approve the authentication using the available authenticator.

Once that succeeds, React gets the credential response just like before:

if (credential) {
  await fetch("/api/passkeys/login/verify", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify(credential.toJSON()),
  });
}

The server then verifies the response using the public credential stored during registration.

Put together, a simple React implementation might look like this:

import { useEffect } from "react";

function Login() {
  useEffect(() => {
    async function startConditionalPasskeyLogin() {
      const supported = await PublicKeyCredential.isConditionalMediationAvailable();
      if (!supported) {
        return;
      }

      const optionsJSON = await fetch("/api/passkeys/login/options", {
        method: "POST",
      }).then((res) => res.json());

      const options = PublicKeyCredential.parseRequestOptionsFromJSON(optionsJSON);

      const credential = await navigator.credentials.get({
        publicKey: options,
        mediation: "conditional",
      });

      if (!credential) {
        return;
      }

      await fetch("/api/passkeys/login/verify", {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
        },
        body: JSON.stringify(credential.toJSON()),
      });
    }

    startConditionalPasskeyLogin();
  }, []);

  return (
    <form>
      <input
        type="email"
        name="email"
        autoComplete="username webauthn"
        placeholder="Email"
      />
      <button type="submit">Continue</button>
    </form>
  );
}

From the user's point of view, there is no separate passkey flow to discover. They click into the same login field they would normally use, and if the browser has a passkey available for the site, it can offer that credential directly.

What breaks when the user gets a new device?​

Getting a new device does not necessarily mean losing access to a passkey.

If the passkey is synced through a credential provider, it may become available again when the user signs in on the new device.

But that will not cover every case. A user might lose access to the credential provider, use a device-bound passkey, or lose the hardware security key that holds it.

So you still need a recovery path for the case where none of the user's passkeys are available.

That recovery path becomes part of your authentication security model, which takes us back to the recovery discussion earlier.

Magic links in React​

Magic links are much simpler than passkeys.

Instead of asking the user for a password, you ask for their email address and send them a short-lived sign-in link.

A basic React form might look like this:

function MagicLinkLogin() {
  const [email, setEmail] = useState("");

  async function sendLink(event) {
    event.preventDefault();
    await fetch("/api/auth/magic-link", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ email }),
    });
  }

  return (
    <form onSubmit={sendLink}>
      <input
        type="email"
        value={email}
        onChange={(event) => setEmail(event.target.value)}
        autoComplete="email"
      />
      <button type="submit">Email me a sign-in link</button>
    </form>
  );
}

Here, /api/auth/magic-link is an endpoint you implement on your backend.

React sends the email address to that endpoint, and the backend creates a cryptographically strong, short-lived token and sends the user an email containing a link.

That link might look something like this:

https://app.example.com/login/callback?token=abc123

The user clicks the link, comes back to your application, and the token is sent to the backend for verification.

If the token is valid and has not expired or already been used, the backend can authenticate the user and create a session.

So the basic flow is:

User enters email
   ↓
React asks backend to send a magic link
   ↓
Backend creates a short-lived token
   ↓
User receives the email
   ↓
User clicks the link
   ↓
Backend verifies the token
   ↓
User is authenticated

Handling the callback route​

Once the user clicks the link in their email, they need somewhere to land in your React application.

Suppose the link points to:

https://app.example.com/login/callback?token=abc123

Your callback page can read the token from the URL and send it back to the backend:

function MagicLinkCallback() {
  const [status, setStatus] = useState("Signing you in...");

  useEffect(() => {
    const token = new URLSearchParams(window.location.search).get("token");

    fetch("/api/auth/magic-link/verify", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      credentials: "include",
      body: JSON.stringify({ token }),
    })
      .then((response) => {
        if (!response.ok) {
          throw new Error("Invalid link");
        }
        setStatus("Signed in");
      })
      .catch(() => {
        setStatus("This sign-in link is invalid or has expired.");
      });
  }, []);

  return <p>{status}</p>;
}

React is not deciding whether the token is valid.

It reads the token from the callback URL and sends it back to the backend that issued it.

The backend checks things such as whether the token exists, whether it has expired, and whether it has already been used.

If those checks succeed, the backend can authenticate the user and establish a session.

The prefetch problem and how to survive it​

There is one slightly awkward problem with magic links.

The first thing that opens the link might not be the user.

Email providers and security products often inspect links inside messages before the user clicks them. They do this to check whether a link might lead to a malicious website.

That can cause problems if simply opening the URL immediately consumes your one-time login token.

For example, this design can be fragile:

GET magic-link URL
   ↓
Token is immediately consumed
   ↓
User clicks the email later
   ↓
Link no longer works

A safer approach is to avoid completing the authentication just because someone performed a GET request.

Instead, the link can first open a confirmation page:

GET magic-link URL
   ↓
Show confirmation page
   ↓
User chooses to continue
   ↓
POST token for verification
   ↓
User is authenticated

The token can still be short-lived and single use.

The difference is that the security-sensitive action only happens after an explicit user action rather than the first time something fetches the URL.

There's one more thing to think about with magic links: the user may not open the link on the same device where they started the login.

They might request the link on a laptop, then open the email on their phone and continue from there.

Whether you allow that is a product decision.

It makes the experience more flexible, but it also means the email account becomes the thing proving the user's identity. The original browser session is no longer necessarily part of that proof.

So when you design a magic-link flow, decide whether cross-device login is something you want to support and what that means for your recovery and security model.

Email and SMS OTP in React​

OTP is the pragmatic middle ground.

There is nothing to enroll.

There is nothing permanent for the user to remember.

And unlike a magic link, the login flow can stay in the original browser.

The user enters their email or phone number, receives a code, and types it back into the application.

Building an OTP input that does not fight the user​

There is a surprisingly easy way to make OTP inputs annoying: build six beautiful individual boxes.

[ 1 ] [ 8 ] [ 4 ] [ 7 ] [ 2 ] [ 9 ]

Now you have to manage:

• focus movement,
• backspace behavior,
• pasting six characters,
• arrow keys,
• screen readers,
• mobile keyboards.

Unless you have a strong UX reason otherwise, a single field is wonderfully boring:

<input
  name="otp"
  inputMode="numeric"
  autoComplete="one-time-code"
  maxLength={6}
/>

Then submit the value normally:

await fetch("/api/auth/otp/verify", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
  },
  credentials: "include",
  body: JSON.stringify({
    email,
    code,
  }),
});

Rate limiting and resend​

Now imagine your login page has this button: Resend code.

And absolutely nothing stopping someone from clicking it 500 times.

You have created both an abuse mechanism and, with SMS, potentially a very expensive button.

Your OTP service needs limits around:

• verification attempts,
• resend attempts,
• code lifetime,
• requests per account,
• requests per IP or other risk signals.

Your UI should reflect those limits instead of pretending retries are unlimited:

<button disabled={secondsRemaining > 0}>
  {secondsRemaining > 0 ? `Resend in ${secondsRemaining}s` : "Resend code"}
</button>

The frontend timer is UX.

The server-side limit is security.

Do not confuse the two.

Why SMS is the weakest option​

SMS OTP is useful.

It is familiar, nearly universal and sometimes the only practical way to reach a user.

But it should not be treated as equivalent to a passkey.

SMS also introduces something email OTP doesn't: a direct delivery cost for every authentication attempt.

That might be insignificant for a small application and very significant at consumer scale.

So if you're choosing between email and SMS OTP purely because both produce a six-digit code, you're looking at the least important similarity.

The channel behind the code is what matters.

Passwordless and MFA are not the same thing​

This deserves its own section because the terms get mixed together constantly.

Passwordless tells you that authentication did not require a password.

Multi-factor authentication tells you that authentication required more than one independent authentication factor.

Those are different properties.

A user signing in with only an email OTP is passwordless.

It is not automatically MFA.

A user signing in using a password and then an Email OTP is using MFA, but the authentication is obviously not passwordless.

And a passkey can have interesting authentication properties of its own, but you should not turn "uses biometrics" into the blanket claim that every passkey login is automatically equivalent to whatever MFA policy your organization requires.

Design the authentication flow according to the assurance you actually need.

Don't derive it from the marketing category the login method happens to sit under.

Implementing with @asgardeo/react​

Everything we've built so far was deliberately low level.

That was useful because now you know where the boundaries are:

React
   ↓
starts authentication
   ↓
Browser / delivery channel
   ↓
interacts with the user
   ↓
Identity system
   ↓
verifies authentication
   ↓
React
   ↓
gets an authenticated session

If you're using WSO2 Identity Platform, you don't need to rebuild those ceremonies inside your React application.

The platform supports passwordless login methods such as Magic Link, Passkey, Email OTP and SMS OTP as configurable authentication options.

Your React integration remains refreshingly small.

import {
  AsgardeoProvider,
  SignInButton,
  SignedIn,
  SignedOut,
} from "@asgardeo/react";

function App() {
  return (
    <>
      <SignedOut>
        <SignInButton />
      </SignedOut>
      <SignedIn>
        <Dashboard />
      </SignedIn>
    </>
  );
}

The important point is that there isn't a separate React passkey implementation hiding inside that button.

Your application starts authentication.

The login flow configured for the application determines whether the user sees a passkey, magic link, OTP, or another authentication method.

That is exactly the separation you want.

Your React code should care that a user became authenticated.

Your identity layer should care how that authentication happened.

Account recovery: the part that decides whether this works​

Let's finish with the part passwordless demos usually skip.

You have removed the password.

Great.

Now remove the user's phone.

Their laptop too.

And access to their old email account.

Can they still recover the account?

Every passwordless system eventually needs an answer to some version of that question.

For passkeys, synchronized credentials make ordinary device replacement considerably easier because credentials may be restored through the user's passkey provider.

But recovery still exists for the cases where those mechanisms are unavailable.

For magic links and Email OTP, recovery effectively inherits the recovery model of the email provider.

For SMS OTP, it inherits part of the recovery and account-transfer model of the mobile carrier.

And every fallback you add can weaken the stronger method sitting above it.

Imagine this authentication policy:

Primary:
  Passkey

Fallback:
  Email OTP

Recovery:
  Email support request

An attacker does not necessarily need to defeat the passkey.

They may simply attack the fallback.

That's why the hardest question in passwordless authentication isn't:

How do I remove the password?

It's:

What evidence will I trust when the user's normal authenticator is gone?

Answer that first.

Then choose the passwordless method.

Conclusion​

Passkeys, magic links and OTP can all remove the password field from your React application.

But that is almost where their similarities end.

Passkeys use public-key cryptography and give you the strongest phishing resistance of the three.

Magic links turn access to an email account into a very simple sign-in experience.

Email and SMS OTP provide an easy, familiar fallback when you don't want users to enroll another credential.

And React itself should stay relatively boring throughout all of this.

It starts the flow.

It presents the UI.

It carries the authentication result back and forth.

The identity system performs the actual verification.

If there is one design decision to make before writing any of that code, though, make it recovery.

Pick your fallback before you pick your primary passwordless method.

Because the strongest login ceremony in the world does not help much if the easiest way into the account is the recovery button underneath it.