Authentication

Stop building auth.
Start shipping product.

Every way to sign in — email, social, magic links, OTP, MFA, passkeys — from one SDK call. Branded login page included. Free for 5,000 users.

Available on Free and above. See pricing

Start free Read the docs

Passkeys / WebAuthn

The credential never leaves the device. Nothing to phish.

A passkey is a public/private key pair minted by the authenticator under the WebAuthn (W3C) and FIDO2 / CTAP standards. On registration the device generates the pair, keeps the private key in hardware (Secure Enclave, TPM, or a security key), and hands your server only the public key. On login the browser signs a server-issued challenge; AuthFI verifies that signature against the stored public key. No shared secret ever crosses the wire, so there is nothing in your database an attacker can steal and replay.

Origin-bound by design: the signature is scoped to your rpId, so a credential minted for your domain is useless on a look-alike phishing site — this is why passkeys are phishing-resistant, not just "strong".
Resident keys (discoverable credentials): the key carries the user handle, enabling usernameless sign-in — the device offers the right account with no email field at all.
Attestation: at registration the authenticator can present a signed statement of its make and model, so regulated tenants can require certified hardware.
The payoff: no password to reset, no OTP to intercept, no shared secret to breach — you delete an entire category of incident from your roadmap.

navigator.credentials.get()

// server issues a one-time challenge; the
// authenticator signs it — private key stays in hardware
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: serverChallenge,   // single-use
    rpId: "auth.acme.com",        // origin-bound
    userVerification: "required" // biometric / PIN
  }
});

// → AuthFI verifies signature vs. stored public key
//   checks rpIdHash, flags (UP+UV), and counter
POST /webauthn/assertion  ⟶  200 session

WebAuthn assertion: a signed challenge, verified server-side. No password field anywhere in this flow.

Branded login

Your brand on the page. Six methods behind one API.

Every login page is fully customizable — your users see your brand at auth.acme.com/login, not ours. Behind it, six sign-in methods are toggled on from the dashboard, each one a configuration flag rather than a fork in your codebase. The hosted page owns the security-sensitive surface — credential handling, redirect validation, rate limiting — so your application never touches a raw password.

Email / Password

Breach detection, progressive lockout, configurable policy.

Social Login

Google, GitHub, GitLab. One click. Profile synced.

Magic Links

Passwordless email login. 15-min single-use tokens.

OTP (Email)

6-digit code, 5-min expiry, 5 attempts max.

MFA (TOTP)

Google Authenticator, Authy. QR enrollment. 10 backup codes.

Passkeys

WebAuthn / FIDO2. Biometric. Phishing-resistant.

Adaptive & step-up MFA

Friction only when the risk is real.

Static "MFA on every login" trains users to click through prompts and still misses session hijacking. Adaptive authentication scores each attempt from contextual signals — network, device, velocity, geography, credential reputation — and only escalates when the score crosses a threshold. A login from a known device on a known network passes silently; a new ASN with impossible travel triggers step-up: re-prompt for a passkey or a TOTP code before the session is issued or a sensitive action proceeds.

Risk-based, not blanket: the same policy that lets trusted sessions through is the one that blocks the anomalous 0.1% — fewer prompts and fewer takeovers.
Step-up at the action, not just the door: re-authenticate for a high-value operation (change email, move money) even inside a live session.
Breach-aware: a credential found in a known breach corpus is itself a risk signal that can force a reset — building on the 700M+ compromised-password check AuthFI already runs.
The payoff: you tune the security/UX trade-off with a policy, not by shipping branching auth logic to every client.

Risk signals → decision

Network New ASN / impossible travel high

Device Unrecognized device fingerprint med

Velocity Failed-attempt burst on the account high

Credential Password in a known breach corpus high

Geo Country never seen for this user med

Reputation IP on a Tor / proxy list low

aggregate score → high → step-up: passkey or TOTP

Signals are weighed per attempt; only a high aggregate score escalates to a second factor.

Drop-in SDK

Three lines of code. Seven languages.

Install the SDK, initialize with your tenant, protect routes. The SDK runs the OAuth 2.0 authorization-code flow with PKCE for you, validates the returned token, and exposes session and permission checks — so passwordless, MFA and risk policy are decisions made in the dashboard, not branches you maintain in seven codebases.

const auth = authfi({ tenant: 'acme' });
app.use(auth.middleware());
app.get('/api/users', auth.require('read:users'), handler);

Security model

Security built in. Not bolted on.

The defenses that matter are the ones that run on every flow without a config flag — and the ones you would otherwise have to build, test, and re-audit yourself for each language and each tenant.

Breached password detection

700M+ compromised passwords checked on every signup and login.

PKCE + token rotation

S256 PKCE on every flow. Automatic refresh token rotation with family detection.

Per-tenant RSA keys

Every tenant gets unique RSA-2048 signing keys. No shared secrets.

S256 PKCE neutralizes authorization-code interception; refresh-token rotation with family detection means a stolen-then-reused token invalidates the whole token family on next use — a replay becomes a logout, not a breach. Per-tenant RSA-2048 (RS256) signing keys mean one tenant's tokens are never verifiable as another's: no shared secret, no blast radius across customers.

Build vs. integrate