WebAuthn changes the shape of the system. The private key stays on the user's device. Your server stores a public key, a credential ID, and a counter. Each registration or login signs a fresh challenge. The browser, the authenticator, and your backend all take part in the ceremony.

This guide walks you through the full path in Node.js. You'll set up the backend, wire registration and login, store passkeys correctly, replace long-lived bearer auth with short server sessions, support backup devices, and add step-up verification for risky actions.

Warning: WebAuthn works in secure contexts. Use localhost for local development, and use HTTPS everywhere else.

Table of Contents

• Why JWT Alone Falls Short

• What WebAuthn Changes

• Initialize the Project

• Install Dependencies

• Define the Data Model

• Build the Server Foundation

• Registration Ceremony

• Authentication Ceremony

• What Replaces the Long-Lived JWT

• Multi-Device and Recovery Logic

• Step-Up Authentication for Sensitive Actions

• Recap

• Try it Yourself

• Final Words

Prerequisites

To follow along and get the most out of this guide, you should have:

• Basic knowledge of JavaScript and Node.js.

• Basic knowledge of TypeScript and Express.

• Basic frontend to backend flow. You should be able to follow fetch() requests from the browser to the server and back.

• A modern browser and a passkey-capable authenticator, such as Touch ID, Face ID, Windows Hello, Android biometrics, or a security key.

• Local testing on localhost. The demo uses localhost as the relying party ID and origin during development.

• No prior WebAuthn knowledge required. The article explains the registration and authentication flow step by step.

Why JWT Alone Falls Short

JWTs are not the villain.

The weak point is the usual deployment pattern around JWTs. Teams often place long-lived tokens in places attackers love, then trust those tokens for too long.

The failure path usually looks like this:

• Your server issues a reusable bearer token.

• The browser stores it.

• Malware, XSS, session theft, or a fake login flow grabs it.

• The attacker replays it.

• Your backend sees a valid token and treats the request as real.

That pattern falls apart fast on high-risk routes. Admin actions, money movement, payout approval, email change, API key creation, or destructive writes deserve stronger proof.

WebAuthn gives you stronger proof because the secret never leaves the authenticator.

In the above diagram, the left side (reusable JWT path) shows the risk of reusable tokens. A server issues a JWT after login. The browser stores the token. An attacker steals the token and sends requests. The backend accepts the token until expiration. Replay becomes possible.

On the right side (WebAuthn path), the flow changes. The server sends a fresh challenge for each login. Your device signs the challenge using a private key stored inside the authenticator. The server verifies the signature before creating a short session.

The key point is simple: JWTs rely on a stored bearer secret, while WebAuthn relies on device-bound cryptographic proof created for a single challenge.

What WebAuthn Changes

WebAuthn uses asymmetric cryptography.

The authenticator creates a key pair. The private key stays on the device. Your backend stores the public key and uses it later to verify signatures. During login, your server sends a fresh challenge. The device signs it, and your backend verifies the result against the stored public key.

That changes three things at once:

• The browser never receives a reusable password secret.

• A stolen public key is useless for login.

• Each ceremony depends on a fresh server challenge.

On the web, passkeys ride on top of WebAuthn. A passkey might live on the local device, a synced platform account, or a physical security key. In practice, your app still deals with the same core objects: credential ID, public key, transports, counter, device type, and backup state.

Initialize the Project

So far, we've talked about why WebAuthn matters and how it changes the login experience. Now it's time to build a small project so you can see the whole flow working end to end.

In this demo, you'll create a simple Node.js app where a user can register a passkey, sign in with that passkey, and then access protected routes through a short-lived session. The idea here is not to build a polished full-stack product. The idea is to build the core backend flow clearly, so you can understand how registration, login, sessions, and step-up verification connect to each other.

Before we start, make sure Node.js and npm are installed on your machine. You can install Node.js from the official website, or use nvm if you prefer managing multiple Node versions.

node -v
npm -v

The expected output is a Node LTS version and an npm version number.

Next, create a new project folder and initialize the basic structure:

mkdir webauthn-node-demo
cd webauthn-node-demo
npm init -y
npx tsc --init
mkdir src

Install Dependencies

Now that your project is initialized, install the required packages.

1. TypeScript and tsx: TypeScript types the backend while tsx runs TypeScript files during development.

npm install -D typescript tsx @types/node
npx tsc -v
npx tsx --version

1. Express and session management: Express handles the HTTP routes, and express-session stores short-lived server session state.

npm install express express-session @types/express @types/express-session

1. SimpleWebAuthn:@simplewebauthn/server generates registration options and verifies responses. @simplewebauthn/browser starts browser-side flows.

npm install @simplewebauthn/server @simplewebauthn/browser

Open your package.json and update the "scripts" block to include these commands:

{
    "scripts": {
        "dev": "tsx watch src/app.ts",
        "build": "tsc",
        "start": "node dist/app.js"
    }
}

Define the Data Model

Before we write the routes, we need to decide how this app will store passkeys.

With password-based login, you usually store a password hash. With WebAuthn, you store something different. After a user registers a passkey, your server needs to keep the credential data required to verify future login attempts. That includes things like the credential ID, public key, counter, and some metadata about the authenticator.

This is why the data model matters from the beginning. Registration and authentication both depend on this stored data, so it's worth making the structure clear before we move deeper into the flow.

A good way to think about it is this. A user can have one or more passkeys, and each passkey should be stored as its own record linked to that user.

Create a new file named src/app.ts. We'll build the backend in this file, and we'll start by defining the data model at the top.

// src/app.ts
type Passkey = {
    id: string;
    publicKey: Uint8Array;
    counter: number;
    deviceType: "singleDevice" | "multiDevice";
    backedUp: boolean;
    transports?: string[];
};

type User = {
    id: string;
    email: string;
    webAuthnUserID: Uint8Array;
    passkeys: Passkey[];
};

const users = new Map<string, User>();

function findUserByEmail(email: string) {
    return [...users.values()].find((user) => user.email === email);
}

What matters here:

• id identifies the credential later.

• publicKey verifies future signatures.

• counter helps detect cloned or misbehaving authenticators.

• deviceType and backedUp give you useful recovery signals.

• webAuthnUserID should be a stable binary value, stored once per user.

Tip: If your database returns Buffer or another binary wrapper for publicKey, convert it back to Uint8Array before verification.

Build the Server Foundation

Next, append the core Express app and relying party settings to src/app.ts:

// src/app.ts
import express from "express";
import session from "express-session";
import { randomBytes, randomUUID } from "node:crypto";
import {
    generateAuthenticationOptions,
    generateRegistrationOptions,
    verifyAuthenticationResponse,
    verifyRegistrationResponse,
    type WebAuthnCredential,
} from "@simplewebauthn/server";

const rpName = "Node Auth Lab";
const rpID = "localhost";
const origin = "http://localhost:3000";

declare module "express-session" {
    interface SessionData {
        currentChallenge?: string;
        pendingUserId?: string;
        userId?: string;
        stepUpUntil?: number;
    }
}

const app = express();

app.use(express.json());

app.use(
    session({
        secret: "replace-this-in-production",
        resave: false,
        saveUninitialized: false,
        cookie: {
            httpOnly: true,
            sameSite: "lax",
            secure: false,
            maxAge: 10 * 60 * 1000,
        },
    }),
);

This gives you the shared state you need for:

• registration challenge tracking

• authentication challenge tracking

• logged-in session state

• short step-up windows for risky actions

Registration Ceremony

Registration is the part where a user's device creates a new passkey and connects it to their account.

You will often see the word ceremony in WebAuthn documentation. In simple terms, it refers to the full exchange between your server, the browser, and the authenticator during registration or login. So when we say registration ceremony, we simply mean the full process of creating and verifying a new passkey.

There are three parts involved here:

• Your backend prepares the registration options and challenge.

• The browser starts the WebAuthn request.

• Then the authenticator, such as a phone, laptop, or security key, creates the key pair and returns the result.

In the above diagram, the registration ceremony links a new passkey to your account. The browser asks the server for registration options. The server generates a challenge and returns a JSON configuration. Next, the browser starts the WebAuthn ceremony. Your authenticator creates a new key pair after biometric or security key verification. The private key stays inside the device. Then the browser sends the attestation response to the server.

Verification happens next. The server checks challenge, origin, and relying party ID. After validation, the server stores credential ID, public key, counter value, device type, and backup state. The account now holds a passkey.

Now that the overall flow is clear, let's build it step by step. We'll start by returning registration options from the backend.

1. Return Registration Options from the Backend

This endpoint creates a new user if needed, generates the registration options, and stores the challenge server-side.

Append the following route to your src/app.ts file:

// src/app.ts
app.post("/auth/register/options", async (req, res) => {
    const { email } = req.body;

    if (!email) {
        return res.status(400).json({ error: "Email is required" });
    }

    let user = findUserByEmail(email);

    if (!user) {
        user = {
            id: randomUUID(),
            email,
            webAuthnUserID: randomBytes(32),
            passkeys: [],
        };

        users.set(user.id, user);
    }

    const options = await generateRegistrationOptions({
        rpName,
        rpID,
        userName: user.email,
        userDisplayName: user.email,
        userID: user.webAuthnUserID,
        attestationType: "none",
        excludeCredentials: user.passkeys.map((passkey) => ({
            id: passkey.id,
            transports: passkey.transports,
        })),
        authenticatorSelection: {
            residentKey: "preferred",
            userVerification: "preferred",
        },
    });

    req.session.currentChallenge = options.challenge;
    req.session.pendingUserId = user.id;

    res.json(options);
});

A few decisions here matter:

• attestationType: 'none' keeps the flow lighter unless you need richer device provenance.

• excludeCredentials stops duplicate registration of the same authenticator.

• userVerification: 'preferred' lets the browser lean toward biometrics or local device unlock.

2. Start Registration in the Browser

On the browser side, you ask your backend for options, then pass them into startRegistration().

Now, create a new file at src/browser.ts to handle the client-side WebAuthn interactions. Add the following function:

// src/browser.ts
import { startRegistration } from "@simplewebauthn/browser";

export async function registerPasskey(email: string) {
    const optionsResp = await fetch("/auth/register/options", {
        method: "POST",
        headers: {
            "Content-Type": "application/json",
        },
        body: JSON.stringify({ email }),
    });

    const optionsJSON = await optionsResp.json();

    const registrationResponse = await startRegistration({ optionsJSON });

    const verifyResp = await fetch("/auth/register/verify", {
        method: "POST",
        headers: {
            "Content-Type": "application/json",
        },
        body: JSON.stringify(registrationResponse),
    });

    return verifyResp.json();
}

Note: Browsers can't run TypeScript or bare npm imports directly. In a real application, you would import src/browser.ts into your frontend framework (React, Vue, and so on) or bundle it using a tool like Vite, Webpack, or esbuild before serving it to the client.

Under the hood, the browser now speaks to the authenticator. That might trigger Face ID, Touch ID, Windows Hello, Android biometrics, or a physical security key prompt.

3. Verify the Registration Response and Save the Passkey

Once the browser sends the response back, verify it against the challenge and relying party details you stored earlier.

Append this verification route to src/app.ts:

// src/app.ts
app.post("/auth/register/verify", async (req, res) => {
    const user = users.get(req.session.pendingUserId ?? "");

    if (!user || !req.session.currentChallenge) {
        return res.status(400).json({ verified: false });
    }

    let verification;

    try {
        verification = await verifyRegistrationResponse({
            response: req.body,
            expectedChallenge: req.session.currentChallenge,
            expectedOrigin: origin,
            expectedRPID: rpID,
        });
    } catch (error) {
        return res.status(400).json({
            verified: false,
            error:
                error instanceof Error ? error.message : "Registration failed",
        });
    }

    if (!verification.verified || !verification.registrationInfo) {
        return res.status(400).json({ verified: false });
    }

    const { credential, credentialDeviceType, credentialBackedUp } =
        verification.registrationInfo;

    user.passkeys.push({
        id: credential.id,
        publicKey: credential.publicKey,
        counter: credential.counter,
        transports: credential.transports,
        deviceType: credentialDeviceType,
        backedUp: credentialBackedUp,
    });

    req.session.currentChallenge = undefined;
    req.session.pendingUserId = undefined;

    res.json({ verified: true });
});

At this point, the user has no password hash in the hot path. The authenticator now holds the private key. Your server stores only what it needs for later verification.

Authentication Ceremony

Authentication is the part where the user proves they still have the passkey they registered earlier. Just like registration, this process is also called a ceremony in WebAuthn. Here, the goal is not to create a new credential. The goal is to verify an existing one in a secure way.

There are four parts involved here:

• Your server creates a fresh challenge.

• The browser passes that challenge to the authenticator.

• The authenticator signs it using the private key stored on the device.

• Then the server verifies the response using the public key it stored during registration.

In the above diagram, login occurs through a challenge-response process. The browser first asks the server for authentication options. The server generates a new challenge and returns the allowed credential list. Your browser then triggers the authenticator. The authenticator signs the challenge using the private key stored on the device. The browser sends the signed assertion to the backend.

Verification follows. The server validates signature, challenge, origin, and credential ID. The stored counter updates. A short session is issued after verification. Login depends on device proof instead of reusable credentials.

With that flow in mind, let's move into the implementation. We'll begin by returning authentication options from the backend.

1. Return Authentication Options

Fetch the user, list allowed credentials, and store the new challenge.

// src/app.ts
app.post("/auth/login/options", async (req, res) => {
    const { email } = req.body;
    const user = findUserByEmail(email);

    if (!user) {
        return res.status(404).json({ error: "User not found" });
    }

    const options = await generateAuthenticationOptions({
        rpID,
        allowCredentials: user.passkeys.map((passkey) => ({
            id: passkey.id,
            transports: passkey.transports,
        })),
        userVerification: "preferred",
    });

    req.session.currentChallenge = options.challenge;
    req.session.pendingUserId = user.id;

    res.json(options);
});

2. Start Authentication in the Browser

The browser receives the options, then starts the ceremony. Add the login function to your src/browser.ts file:

// src/browser.ts
import { startAuthentication } from "@simplewebauthn/browser";

export async function loginWithPasskey(email: string) {
    const optionsResp = await fetch("/auth/login/options", {
        method: "POST",
        headers: {
            "Content-Type": "application/json",
        },
        body: JSON.stringify({ email }),
    });

    const optionsJSON = await optionsResp.json();

    const authenticationResponse = await startAuthentication({ optionsJSON });

    const verifyResp = await fetch("/auth/login/verify", {
        method: "POST",
        headers: {
            "Content-Type": "application/json",
        },
        body: JSON.stringify(authenticationResponse),
    });

    return verifyResp.json();
}

3. Verify the Assertion and Update the Counter

This is the moment where the backend decides whether the login is real.

// src/app.ts
app.post("/auth/login/verify", async (req, res) => {
    const user = users.get(req.session.pendingUserId ?? "");

    if (!user || !req.session.currentChallenge) {
        return res.status(400).json({ verified: false });
    }

    const passkey = user.passkeys.find((item) => item.id === req.body.id);

    if (!passkey) {
        return res
            .status(400)
            .json({ verified: false, error: "Passkey not found" });
    }

    const credential: WebAuthnCredential = {
        id: passkey.id,
        publicKey: passkey.publicKey,
        counter: passkey.counter,
        transports: passkey.transports,
    };

    let verification;

    try {
        verification = await verifyAuthenticationResponse({
            response: req.body,
            expectedChallenge: req.session.currentChallenge,
            expectedOrigin: origin,
            expectedRPID: rpID,
            credential,
            requireUserVerification: true,
        });
    } catch (error) {
        return res.status(400).json({
            verified: false,
            error:
                error instanceof Error
                    ? error.message
                    : "Authentication failed",
        });
    }

    if (!verification.verified) {
        return res.status(400).json({ verified: false });
    }

    passkey.counter = verification.authenticationInfo.newCounter;

    req.session.userId = user.id;
    req.session.currentChallenge = undefined;
    req.session.pendingUserId = undefined;

    res.json({ verified: true });
});

Two details here matter more than they first appear:

• requireUserVerification: true forces a stronger ceremony for the verification step.

• newCounter should overwrite your stored counter after each successful login.

That counter update is one of the few signals you have for spotting cloned or broken authenticators.

What Replaces the Long-lived JWT

Don't run this full WebAuthn flow, then issue a week-long bearer token and call the job done. That throws away the best part of the design.

A better model is:

• WebAuthn proves identity

• the server creates a short session

• the browser receives only an HTTP-only session cookie

• risky actions ask for a fresh WebAuthn assertion again

A tiny route guard shows the idea:

// src/app.ts
function requireSession(
    req: express.Request,
    res: express.Response,
    next: express.NextFunction,
) {
    if (!req.session.userId) {
        return res.status(401).json({ error: "Unauthorized" });
    }

    next();
}

app.get("/me", requireSession, (req, res) => {
    const user = users.get(req.session.userId ?? "");

    if (!user) {
        return res.status(404).json({ error: "User not found" });
    }

    res.json({
        id: user.id,
        email: user.email,
        passkeys: user.passkeys.length,
    });
});

This keeps the post-login browser state smaller and less reusable. The browser carries only a session cookie. The server owns the session state and its lifetime.

Tip: Short sessions plus fresh WebAuthn for risky actions is a stronger shape than one long bearer token with broad scope.

Multi-Device and Recovery Logic

Strong auth fails fast if the first lost phone locks the user out forever. You need a real backup story from day one.

The clean pattern looks like this:

• register one platform passkey on the user's main device

• register one extra credential, such as a security key or another trusted device

• verify a contact channel during account setup

• expose passkey management in account settings

• store device metadata so users see what is registered

In the above diagram, the left side shows the recovery strategy. You start with a primary passkey on your main device. Then you add another trusted authenticator such as a second device or hardware security key. A recovery channel should exist. Device inventory helps track active credentials, and lost devices must be revoked quickly.

The right side focuses on step up authentication. Sensitive actions require fresh verification. Examples include payouts, email change, API key generation, or destructive operations. When such an action begins, the server issues a new challenge. Your authenticator signs again. Access lasts for a short step up window before new verification becomes required.

A simple product rule helps here. Don't hide the second passkey flow inside a deep settings page. Put "Add another passkey" right after the first successful registration.

Passkeys also sync across major platform ecosystems. That helps the user experience, but your backend should still treat each registered credential as a first-class record with its own ID, public key, counter, device type, and backup state.

For account recovery, keep the bar high. Recovery should not become the weakest path in the whole system. Emailed magic links, recovery codes, and support-driven recovery all need rate limits, audit trails, and strict checks.

Step-up Authentication for Sensitive Actions

Logging in once should not grant silent permission for every dangerous route.

Step-up auth means this:

• the user is already signed in

• they try a sensitive action

• the server demands a fresh WebAuthn ceremony

• the app grants a short window for that one class of actions

You can use step-up auth for:

• payout approval

• credential management

• email or phone change

• API key creation

• organization deletion

• role elevation

• access to billing controls

Start by issuing new authentication options with strict user verification.

// src/app.ts
app.post("/auth/step-up/options", requireSession, async (req, res) => {
    const user = users.get(req.session.userId ?? "");

    if (!user) {
        return res.status(404).json({ error: "User not found" });
    }

    const options = await generateAuthenticationOptions({
        rpID,
        allowCredentials: user.passkeys.map((passkey) => ({
            id: passkey.id,
            transports: passkey.transports,
        })),
        userVerification: "required",
    });

    req.session.currentChallenge = options.challenge;

    res.json(options);
});

Then verify the response and issue a short step-up window.

// src/app.ts
app.post("/auth/step-up/verify", requireSession, async (req, res) => {
    const user = users.get(req.session.userId ?? "");
    const passkey = user?.passkeys.find((item) => item.id === req.body.id);

    if (!user || !passkey || !req.session.currentChallenge) {
        return res.status(400).json({ verified: false });
    }

    let verification;
    try {
        verification = await verifyAuthenticationResponse({
            response: req.body,
            expectedChallenge: req.session.currentChallenge,
            expectedOrigin: origin,
            expectedRPID: rpID,
            credential: {
                id: passkey.id,
                publicKey: passkey.publicKey,
                counter: passkey.counter,
                transports: passkey.transports,
            },
            requireUserVerification: true,
        });
    } catch (error) {
        return res.status(400).json({
            verified: false,
            error: error instanceof Error ? error.message : "Step-up failed",
        });
    }

    if (!verification.verified) {
        return res.status(400).json({ verified: false });
    }

    passkey.counter = verification.authenticationInfo.newCounter;
    req.session.stepUpUntil = Date.now() + 5 * 60 * 1000;
    req.session.currentChallenge = undefined;

    res.json({ verified: true });
});

A tiny guard handles the rest.

// src/app.ts
function requireRecentStepUp(
    req: express.Request,
    res: express.Response,
    next: express.NextFunction,
) {
    if (!req.session.stepUpUntil || req.session.stepUpUntil < Date.now()) {
        return res.status(403).json({ error: "Fresh verification required" });
    }

    next();
}

app.post("/billing/payout", requireSession, requireRecentStepUp, (req, res) => {
    res.json({ ok: true });
});

This is where WebAuthn stops being a login feature and starts becoming part of your authorization model.

Now that all your routes and guards are built, append the server start command to the very bottom of src/app.ts to bring the backend to life:

// src/app.ts
const PORT = 3000;
app.listen(PORT, () => {
    console.log(`Server listening on http://localhost:${PORT}`);
});

Recap

You started with a common weak pattern: a reusable token trusted for too long. Then you replaced the core proof model:

• the device keeps the private key

• the server stores the public key and counter

• each ceremony signs a fresh challenge

• the app uses short server sessions after verification

• risky routes trigger fresh step-up authentication

That's the real shift.

WebAuthn is not a cosmetic login upgrade. It changes where trust lives. Once you move from reusable bearer proof to device-bound cryptographic proof, your Node.js auth stack starts to behave like a modern security system instead of a thin session wrapper.

Try it Yourself

The full source code is available on GitHub. Clone the repository here and follow the setup guide in the README to test the biometric login flow locally.

Final Words

If you found the information here valuable, feel free to share it with others who might benefit from it.

I’d really appreciate your thoughts – mention me on X @sumit_analyzen or on Facebook @sumit.analyzen, watch my coding tutorials, or simply connect with me on LinkedIn.

You can also checkout my official website www.sumitsaha.me for more details about me.

With the rise of cyber-threats, companies need to ensure that their users are authenticated before accessing any sensitive information. This helps protect the online safety of both parties.

In the past, the most common authentication method that we're all likely familiar with was using a username and password to sign in to apps and services.

And if you're a programmer, you've likely developed projects where you have implemented this method as a form of authentication.

But hey! Guess what? Things have changed over the past couple of years. With advancements in technology, this means security has to be taken more seriously and we need more strict authentication approaches.

And that's what we'll learn about in this tutorial.

Different Authentication Methods

There are many different methods of authenticating users, and each has its own advantages and disadvantages. The most common methods of user authentication are:

• username and password,
• two-factor authentication,
• biometrics

just to list a few.

But as time passes, we continue to evolve and new methods are introduced that provide a safer way to store user data. Some examples of these methods include:

• Passwordless login
• Multi-factor authentication, and
• Token-based authentication

In this article, we will explore the most common methods of user authentication. By understanding the different options available, you can choose the best method for your needs.

But first, let's understand what we mean by authentication.

What is User Authentication?

To better understand what authentication is all about, we can relate it to a real world example.

Let's take a scenario where you are out at the store shopping and you need to make a payment with your credit card. You go through the steps of swiping your card to authenticate the payment, but what really happens before the transaction is complete?

After swiping your card, the machine will read the card info and send it to the issuer for verification. The issuer will then check for a couple of things in order to verify the transaction.

In this case, the issuer will check the card info against what is on record, like expiry date, card number, and account balance. If everything matches what is on record and there are sufficient funds, an authorization message is sent and the transaction is allowed.

In a case where the info doesn't match and/or there are not enough funds, a decline message is instead sent and the transaction is declined.

Now with this understanding, authentication is the process of verifying the identity of a user. User authentication verifies the identity of a user before granting access to sensitive information or systems.

What are some common authentication methods?

There are many ways to authenticate a user, and each platform has different methods that they use. But as I mentioned above, some common methods include username and password, fingerprint, facial recognition, and iris scan.

Username/password authentication

Username and password are the most common form of authentication. This is where a user enters their username and password into a login form, and if the credentials match what is stored in the database, the user is granted access.

But keep in mind that this method can be insecure if passwords are not properly encrypted or if users reuse the same password for multiple accounts.

Biometric authentication methods

Fingerprint authentication uses an individual's unique fingerprint to verify their identity. This can be done using a fingerprint scanner or by using a smartphone's built-in sensor.

This method is most commonly used in smart phones and recently there has been an increase in the use of this method in laptops, too.

Facial recognition works in a similar way, using an image of the user's face to verify their identity. Iris scanning is another biometric authentication method that uses an image of the user's iris to identify them.

More Secure Authentication Methods

Even though these have historically been the most common methods, recently we have seen a rise in other methods which are said to be more secure.

In fact, many organizations are turning to these techniques in addition to the user providing a username and password. This is considered an extra layer of security.

These newer techniques include:

1. Two-Factor Authentication

Two-factor authentication, also known as 2FA, is an additional layer of security that can be used to protect your account.

2FA is a way of verifying a user from two different approaches, thats is: using something the user already knows (like their username and password), and using something the user has, like a phone.

When 2FA is enabled, apart from entering the username and password correctly, you will be prompted for the second piece of information (usually a code generated by an app on your phone or a code sent via SMS). This makes it much more difficult for someone to gain access to your account, even if they have your password.

2FA is not foolproof, but it is more secure compared to using only username and password. This makes it a valuable tool to help keep your account safe. If you are concerned about the security of your account, enabling 2FA will be of great help.

2. Passwordless Login

Passwordless login, just as the name suggests, is a method of logging into an account without needing a username or a password. There are many reasons why you might want to stop using a password and opt for a passwordless login experience.

For one, it's more convenient for users. They don't have to remember yet another username and password combination. And two, it's more secure. There are no weak passwords to be guessed or brute-forced by attackers.

So how do you set up a passwordless login? There are a few different methods you can use, each with its own set of pros and cons.

Different methods of passwordless login

One popular method is to use an email link. When the user wants to log in, they provide their email address. They then receive an email with a link that expires after a certain amount of time. When they click the link, they're logged in without having to enter a password.

Another option is to use a one-time code generated by an app on the user's phone. The code is valid for only a short period of time, so even if someone were to intercept it, they wouldn't be able to use it.

Which method is best for you depends on your security needs and preferences. But whatever you choose, ditching the password is sure to make life easier for your users - and make your site more secure in the process.

For a practical guide on how to use the passwordless method, Auth0 has a step-by-step video guide on how to implement this.

3. Multi-factor Authentication

Also known as MFA, multi-factor authentication is an authentication method that requires a user to verify their identity by providing more than one piece of information that identifies them. This can range from something the user knows, has, or is.

This means that in addition to having a username and password, you will be required to provide extra proof depending on the system you are trying to access. This extra proof can range from a fingerprint to a secret security key or even a code generated randomly.

A good example of this authentication is when you set up an online banking system. Despite having entered a correct username and password, your might be required to either provide your fingerprint or even a code in order for some transaction to happen.

This means that even if someone was to obtain your username and password, they would still need your fingerprint or a code that has been sent to your phone in order to accomplish a specific task.

4. Token-Based Authentication

Token-based authentication is a method of authenticating users that involves providing them with a unique token. This token can be used to identify the user and provide access to certain resources. The toke usually contains a string of characters generated by the system that's sent to the user's device or email.

There are many benefits to using token-based authentication, including improved security and scalability.

Tokens, while costly and inconvenient at times, provide a greater level of security than passwords or biometrics since they are only issued when requested. In addition to this, they can also be set to expire after a certain period of time, making it more secure compared to the traditional approaches.

This method is relatively new and it has become more popular in recent years as web applications have become more complex and distributed across multiple servers. It offers several other advantages over other methods.

With token-based authentication, the token is stored on the client side, making it much more secure. In addition, since there's no need to store tokens on the server, scaling becomes much easier.

Overall, token-based authentication offers better security and performance than other methods. If you're looking to implement an auth system for your web application, consider using tokens.

Conclusion

User authentication is a critical part of any application, whether it's mobile or web.

It is important to choose an authentication method that is both secure and easy to use.

There are many different factors to consider when choosing an authentication method, but the most important thing is to choose one that will protect your users' data. Hopefully this article has given you some insights into how to do that.

“Zaphod’s just this guy, you know?”

– Halfrunt, Hitchhiker’s Guide to the Galaxy by Douglas Adams. The book, not the movie. Definitely not the movie.

Some people (??‍) are really into cybersecurity, end-to-end encryption, and totally geeked out when they first learned how the Enigma worked. These people are likely to have an innate interest in building a less-than-laughable personal cybersecurity posture.

Most people, unfortunately, consider cybersecurity optional. Most people say things like:

“There’s no one targeting lil ol’ me.”
“I have nothing to hide, anyway.”
“I’m too busy to learn all this stuff. Why can’t someone just give me a simple summary of best practices that I can skim in approximately seven minutes?”

To those people, I say, hello, hypothetical incorporeal reader! Here is a simple summary of best practices that you can skim in approximately seven minutes.

Wait why do I care

You may have a hard time understanding why cybersecurity matters when you’re just an average person. Sure, you don’t want your devices hacked or your personal data stolen, but it’s not like anyone is coming after you, specifically, right?

Hey Alex, I’ll take “right,” for $400. It’s unlikely anyone is attempting to steal your particular stuff, although I must admit that Persian rug of yours would really tie the room together. Instead, it can help to understand cybersecurity if you think of it in terms of low-hanging fruit.

You’ve got some fruit, I’ve got some fruit. Joe from down the block has a 1.21 gigawatt flux-capacitor-powered fruit-snatching robot. Joe doesn’t know either of us exist, but his robot goes (very quickly) from door to door, all the way around the block, looking for fruit. If my front door is locked and yours is standing open, whose fruit is Joe’s robot going to snatch?

If that sounds like boring, old, regular security, you’re correct! Cybersecurity isn’t about finding some magic spell that makes your fruit maximally secure. It’s about making your fruit more secure than the fruit next to you. You do this by employing some thoughtful habits, in much the same way as you learned to lock your front door to guard against fruit-snatching robots.

Security breaches and incidents happen every day. Most of them occur because an automated scanner cast a wide net and found a person or company with lax security that a hacker could then exploit. Don’t be that guy.

Wait what's a security posture anyway

Here is how the National Institute of Standards and Technology defines security posture:

The security status of an enterprise’s networks, information, and systems based on information assurance resources (e.g., people, hardware, software, policies) and capabilities in place to manage the defense of the enterprise and to react as the situation changes. (NIST Special Publication 800–30, B-11)

The important bit above is, “capabilities in place to manage the defense of the enterprise.” In the context of personal security, you are the enterprise. Congratulations. May you boldly go where no man has gone before.

Before you explore strange new worlds (it is the Internet, after all), there are steps you can take to manage your defenses. The word “capabilities” is apt, as having certain things in place will pretty much give you cybersecurity superpowers. Here are the three steps I consider most important and beneficial:

1. Use multifactor authentication
2. Use a VPN
3. Develop healthy skepticism

With these three keys in hand, your cybersecurity posture goes from being robot lunch to War Games — where the winning move for an attacker is not to play.

1. Use multifactor authentication

Passwords are dead. Computationally, they are a solved problem, and cracking passwords is just a matter of time. Unfortunately, many people still help to speed up the process by using the same compromised passwords for multiple accounts, putting themselves at risk for inconceivable benefit. Pass phrases are longer and more complicated, and would take a lot more time to crack. I highly recommend them; even so, your password ultimately doesn’t matter.

The answer, at least for now, is multifactor authentication (MFA). MFA is made up of three kinds of authentication factors:

1. Something you know, like a pass phrase;
2. Something you have, like a chip pin card or phone; and
3. Something that you are, like your face or fingerprint.

Two or more of these factors are infinitely better than a password alone, especially if your password is on this list.

Multiple authentication factors are now widely supported by account providers and social media sites. If you have the choice, avoid using text messages as a way of receiving authentication codes. SMS authentication leaves you vulnerable to the SIM swap attack — please direct further questions to Jack Dorsey. Instead, use an authenticator app like Google Authenticator to generate codes on your device. This ensures that you alone, using that particular device, will have the correct authentication code. No power in the ‘verse can stop you.

The Google Authenticator app works with the specific device you set it up on, so when you get a new device you will need to move Google Authenticator to your new phone. Hardware authentication keys such as the YubiKey may present less hassle when switching devices, but aren’t yet as widely supported as authentication apps.

2. Use a VPN

The difference between using a VPN and not using one is like how The Dark Knight Rises was really good and Batman v Superman was really, really bad. Same franchise, totally different standards.

Let’s say you send a lot of mail, but never bother to put your letters in envelopes or even fold them in half. Anyone who bothers to look will know that you’re not really the Dread Pirate Roberts after all. When you use a Virtual Private Network, especially if you often connect to public WiFi, it’s like putting your letters into cryptographically-sealed envelopes and sending them via a special invisible courier service. No one but the intended recipient can read your letters, and no one but you and the courier know to whom the letters are sent.

VPNs prevent others from reading your communications, like opportunistic attackers who scan open WiFi, and even your own Internet Service Provider (ISP) who may sell your usage data for advertising dollars.

Choosing a trustworthy VPN provider requires some research, and is in itself material enough for a separate article. As a starting point, look for providers with firm policies against logging, and expect to pay between $5-$10 USD monthly for the service. Avoid free VPN apps and services with ambiguous privacy policies; they’ll typically cost you much more than you’ll know.

3. Develop healthy skepticism

Ultimately, the weakest link in your cybersecurity defense is you. All the MFA and VPNs on the Internet won’t protect you if a scam or malware bot can trick you into opening the front gates. Yes, I know it’s a very nice looking wooden horse. Also free. Did you order it? No? Then it can stay outside.

Always look a Trojan gift horse in the mouth.

Develop the habit of second-guessing things delivered to your virtual doorstep. Email, phone, and messaging scams range in sophistication, from rickety robot-assembled shotgun blasts to elaborate social engineering attacks that use cognitive biases very effectively. Don’t assume you’re too clever for them; humans are very predictable creatures. After all, nobody expects the Spanish Inquisition.

Instead, ask questions. Double check communications that ask you to click on links or visit a website, even if they come from someone you know or a company you use. If you’re not certain, based on a previous in-person interaction, that your friend or bank or mother sent this email, pick up the phone and call them. Even if you think you are certain, pick up the phone and check. You don’t call your mother enough, anyway.

Oh, and if the person on the phone is from your local tax office or the IRS or the CRA and they’re about to freeze your accounts because a case of mistaken identity has resulted in you being criminally charged for not repaying a loan on a 600-foot yacht in Malibu, just hang up. You know better than that. Tax agencies don’t have phones.

Your personal cybersecurity starter pack

You now have three keys to open three gates to a robust personal cybersecurity posture. If those keys have also unlocked your curiosity, there’s plenty more rabbit hole to go down. I highly recommend the Security in Five podcast for Binary Blogger’s great advice, which inspired much of this post. Surveillance Self Defense offers the Electronic Frontier Foundation’s tips on securing online communication. Troy Hunt also has a YouTube series entitled Internet Security Basics that goes into more depth on how to protect yourself online.

For now, I hope you use your newfound cybersecurity powers for good. Mind what you have learned. Save you it can.

A quick search for React Native biometric authentication would give you several tutorials. That was the first thing I did when there was a need for such a feature in one of my projects. Depending on the level of risk acceptable for your app, one of those solutions might be suitable. For a high risk app like ours, it would not pass security testing.

If you want to add a secure biometric authentication to aa React Native iOS app, you are in the right place.

What is wrong with react-native-touchid?

Most implementations use the react-native-touchid package. At line 65 in the TouchID.m file, the authenticate method calls the following LAContext method when attempting TouchID/FaceID authentication:

evaluatePolicy:localizedReason:reply:^(BOOL success, NSError *error)

The method relies on a Local Authentication check if the provided fingerprint matches the one enrolled on the device. When the check passes, a success boolean is returned and the user has authenticated successfully with TouchID/FaceID.

There have been reports of the possibility to bypass Local Authentication by sending a success signal to Apple’s APIs on jailbroken or non-jailbroken iOS devices. Thus, biometric authentication via Local Authentication is vulnerable to spoofing by an attacker who could interfere with the check at runtime.

What is the secure way to implement biometric authentication?

To implement biometric authentication in an iOS app, there are two ways — either through Apple’s Local Authentication APIs or through access control of Keychain Services natively provided by the underlying system.

Authenticating with Local Authentication is simpler but generally not recommended for critical applications. As described in the previous section, Local Authentication is a high level API whose behaviour can be overridden, i.e. an attacker could fake a successful authentication by changing the API’s response.

It is acknowledgedly best practice to use Keychain Services for implementing biometric authentication in high risk apps. Keychain Services enforces access control on its stored content using functionality provided by iOS and Secure Enclave. The process executes at the hardware and operating system layer and thus minimises exposure to the less trustworthy application layer. Security risks do exist when user is on a jailbroken or malware-infected device, but these threats can be mitigated by mobile device management (MDM) technology.

How do we implement biometric authentication with Keychain Services?

In order to access Keychain Services in our React Native app, we are going to use the package react-native-keychain. The example code is in TypeScript, which should easily be converted to JavaScript.

First, install react-native-keychain and its type declaration as your project dependency:

npm i -S react-native-keychain

npm i -S @types/react-native-keychain

Next, we have to link the library as it depends on the native component. There are two ways of linking libraries in a React Native app: automatic linking and manual linking. I encountered many errors with CocoaPods while performing automatic linking. Manual linking works but involves many steps.

I discovered that the library is linked properly without errors if you run react-native link after temporarily removing Podfile under the iOS folder. To save you the hassle, let’s follow such a hybrid approach. Assuming your code is under version control so that it is possible to safely revert any changes, delete your Podfile, then run the linking command:

react-native link react-native-keychain

Now, undo your Podfile deletion. For iOS 10 you’ll need to enable the Keychain Sharing entitlement in the Capabilities section of your build target.

Add the following key value pair to Info.plist:

<key>NSFaceIDUsageDescription</key><string>Enabling Face ID allows you quick and secure access to your account.</string>

Then rebuild your project with:

react-native run-ios

In case you encounter difficulty in installing react-native-keychain, refer to this GitHub README.

Before asking the user to authenticate with TouchID/FaceID, it is wise to check if the user’s iOS device supports such capability by calling [getSupportedBiometryType](https://github.com/oblador/react-native-keychain#getsupportedbiometrytype):

After confirming that biometric authentication is supported, you need to save some content in the keychain and set access control flags. The content could be user credentials or some access token. Keychain entry is encrypted and stored in secure storage. To store a value in the keychain, call [setGenericPassword](https://github.com/oblador/react-native-keychain#setgenericpasswordusername-password--accesscontrol-accessible-accessgroup-service-securitylevel-) :

A few points to note here:

• Setting accessControl to any of these [Keychain.ACCESS_CONTROL](https://github.com/oblador/react-native-keychain#keychainaccess_control-enum) enum values BIOMETRY_ANY , BIOMETRY_CURRENT_SET , BIOMETRY_ANY_OR_DEVICE_PASSCODE , BIOMETRY_CURRENT_SET_OR_DEVICE_PASSCODE mandates that the user authenticate with TouchID/FaceID whenever we attempt to retrieve the keychain item.
• We also set accessible to Keychain.ACCESSIBLE enum value WHEN_PASSCODE_SET_THIS_DEVICE_ONLY . This is the strictest accessible constraint, which enforces:

Your device must be unlocked for the secret to be accessible.

Your device must have a device passcode set.

If you turn off your device passcode, the secret is deleted.

The secret cannot be restored to a different device.

The secret is not included in iCloud backups.

Finally, we trigger the TouchID/FaceID authentication prompt by attempting to access the previously stored keychain value with [getGenericPassword](https://github.com/oblador/react-native-keychain#getgenericpassword-authenticationprompt-service-) :

Since we saved our secret with access control previously, accessing the item requires user to pass biometric authentication. When authentication is successful, the result returns an object, whose username is ‘your-secret-name’, password is ‘your-secret-value’, and service is ‘your-service-name’.

After 5 failed attempts of TouchID/FaceID authentication system-wide, biometric authentication is turned off everywhere on the device. The user must lock and unlock the device with a passcode to re-enable TouchID/FaceID. That’s why at line 14 we have to check for supported biometry type and handle the case appropriately, e.g. asking the user to login with their username/password.

Caveats

Though biometric authentication with react-native-keychain is suitable for critical applications, there are a few caveats I would like to bring to your attention:

There is no passcode fallback. You may receive a requirement to allow the user to authenticate with their device passcode. Looking at the package’s README, you should find Keychain.ACCESS_CONTROL enum keys DEVICE_PASSCODE , BIOMETRY_ANY_OR_DEVICE_PASSCODE , BIOMETRY_CURRENT_SET_OR_DEVICE_PASSCODE .

Unfortunately, setting an access control value when calling setGenericPassword to any of those three enum keys do not enable an “Enter Password” fallback. The issue has been reported on GitHub, but there has been no response at the time of publishing this article.

You may think of implementing passcode fallback with a different library. Be aware that your system is only as secure as your weakest link. If your passcode fallback implementation executes at the application layer, it is a potential target for a security attack and defeats the purpose of relying on Keychain Services for biometric authentication.

Also, authenticating with react-native-keychain on Android devices may not be considered secure as there is no equivalence of Keychain Services in Android.

Wrapping up

Thank you for reading this far. I hope you’ve found the tutorial useful. One improvement you may want to make is asking the user whether they would like to opt-in for biometric authentication before enabling it in your app. Also, you may add a setting to let the user turn on or off TouchID/FaceID authentication in your app settings page.

References

• Why local authentication is not secure
• How Keychain Authentication with Touch ID Works