Introducing Prelude Auth: What Authentication Is, and How We’re Rethinking It

Why most auth stacks have blind spots between verification, fraud, and login, and how Prelude Auth closes the gap.

Rowan Haddad

Content & SEO Manager

Summary

Authentication is the ongoing process of confirming that the person in a session is who they claim to be- distinct from verification, which confirms identity details once, at the start. Most auth stacks treat these as separate problems solved by separate vendors, which means the signals gathered during signup never reach the login flow that follows. Prelude Auth closes that gap: it's built directly on top of Prelude's verification and fraud signals, so every authentication decision, from first login to a step-up challenge months later, has the full picture, not just a password check. We announced Auth alongside our Series A in May; this is the deeper look at what it actually does.

What is Authentication, Actually?

Authentication answers one question, over and over: is this the same person who was here before?

It's easy to conflate authentication with verification, because they usually happen minutes apart and feel like one continuous flow to the user. But they're solving different problems, on different schedules:

Verification happens once, usually at signup. It confirms that a piece of information, such as a phone number, an email, or a document, is real and belongs to the person providing it.
Authentication happens every time after that. It confirms that whoever is currently in the session is the same person who verified in the first place.

Verification is a one-time gate. Authentication is a standing question, asked again at every login, every sensitive action, every returning visit. A banking app doesn't verify your phone number every time you check your balance but it does authenticate you every time you open the app.

Most authentication methods fall into three categories: something you know (a password), something you have (a phone, a security key), and something you are (a fingerprint, a face). Modern auth stacks usually combine at least two -multi-factor authentication - because any single factor is one leaked database away from being useless.

That part of the picture is well understood. What's less well understood and what actually breaks in production is what happens between verification and authentication, and what happens after the first login.

Where Most Auth Stacks Have Blind Spots

If you've built or bought authentication before, this will sound familiar. A typical stack looks like this: a verification provider handles the OTP, a fraud vendor scores risk separately, an identity provider manages login sessions, and a device-fingerprinting SDK sits on top, mostly disconnected from the other three.

Each piece does its job. None of them talk to each other. That creates three specific blind spots:

Sessions live in isolation. A user verifies their phone number, confirms a device, and passes a fraud check during signup. Then they log in and the session that gets created knows none of it. All that signal, gathered seconds earlier, evaporates the moment authentication starts.

Fraud detection happens too late. Risk scoring is usually a separate layer, blind to what happened during onboarding and phone verification. A user who looked risky at signup can log in freely afterward, because nothing carried that risk score forward.

AI has no answer in legacy auth. Most authentication was designed around a simple assumption: every session belongs to a human. That assumption has already broken.

Cloudflare Radar data, shared by CEO Matthew Prince in June 2026, showed automated requests accounting for 57.5 percent of HTTP traffic to HTML content, against 42.5 percent from humans, the first time bots have outnumbered people online in the internet's history, arriving roughly eighteen months earlier than Cloudflare's own forecast. Legacy auth has no mechanism for telling a legitimate agent from a malicious one, because it was never built to ask the question in the first place.

This isn't a hypothetical problem. Session hijacking in particular has become the preferred way around traditional login defenses: SpyCloud's 2026 Identity Exposure Report recorded 8.6 billion stolen session cookies and artifacts recaptured from the criminal underground in a single year, and by July 2026 the company had surpassed one trillion total recaptured identity assets, with stolen session data specifically named as having overtaken passwords as attackers' top target. A stolen session cookie skips the login form entirely. None of the blind spots above are equipped to catch that.

Why we Built Prelude Auth

The Prelude product didn't start with authentication. Prelude started as a phone verification API, routing, delivering, and scoring OTPs for companies like BeReal, Sunday, Suno, and Voodoo.

The gap became obvious from there: most companies don't have one tool with a blind spot, they have three. It was some version of: a verification tool, a fraud tool, and an auth tool, and none of them know about each other. Authentication was the layer still missing: the piece that decides whether a returning session is trustworthy, using the same signals already being collected at signup.

That's the problem Prelude Auth solves.

It isn't a bolt-on session manager sitting next to our verification API. It's built on the same signal graph. Device ID, network fingerprint, and fraud score generated during phone verification flow directly into every authentication decision, every step-up trigger, and every session trust score that follows. The question stops being "is this a valid phone number?" at signup and "is this a valid password?" at login, asked by two systems that never compare notes. It becomes one continuous question, answered by one platform: is this a real, trusted user?

What Prelude Auth Actually Does

Prelude Auth is a complete authentication API: user management, multi-method login, session tracking, and profile management, all through one REST interface.

Every login method your users expect. OTP login over SMS or email, email-and-password with configurable rules, and social login via Google, Apple, Microsoft, GitHub, and Okta. SSO over SAML is ready on day one, so closing an enterprise deal doesn't mean building auth infrastructure from scratch.

Signals that carry forward, not just at login. SMS OTP and email OTP carry Verify API signals directly into the session. Every other login method feeds the same device trust graph, so a user who verified via OTP once doesn't need to re-verify to change a password. Auth tracks verification state per session and carries it forward into whatever they do next.

Step-up authentication, on your terms. For sensitive actions such payments, password changes, or data exports, Auth calls a webhook on your backend with full context, and you decide what happens next. Mix and match step types freely: verify_sms, verify_email, biometric_check, kyc_review, document_scan, security_question.

Bot and agent detection at the edge. Network fingerprinting identifies clients before they hit the auth flow at all, whether that client is a browser, a mobile app, or an AI agent. Device ID correlation stops synthetic accounts and automated attacks without adding friction for real users. This matters more given the passkey shift happening industry wide: FIDO Alliance's 2026 State of Passkeys report puts global passkey adoption at roughly 5 billion in active use, with 90 percent consumer awareness and 68 percent of enterprises now deploying or actively rolling out passkeys for employee sign in. As passwords fade, the signal that matters shifts from what a user knows to what device and session they are actually operating from, which is exactly what device correlation is built to answer.

Security enforced at the protocol level. Every session uses RFC 9449 DPoP, proof-of-possession tokens bound to the client's key pair, with automatic revocation across all sessions if a token gets reused. Every social login goes through PKCE, so a stolen token is useless without a verifier that never leaves the browser.

Built to migrate into, not around. Clean REST, standard JWTs, and SDKs for iOS, Android, and React Native that follow familiar patterns. Import existing users and custom fields via the Management API, with no forced re-authentication. A full auth flow- start OTP, check OTP, get session - fits in under 15 lines of code.

Underneath all of it: SOC 2 Type II and ISO 27001 certification, data encrypted at rest and in transit, hosted in the EU, and never sold or shared.

Why Teams are Switching

The teams moving to Prelude Auth aren't usually chasing a single feature. They're consolidating: replacing a verification provider, a fraud vendor, and an identity provider with one platform that shares a signal graph instead of three that don't.

Customers have actually saved more than 50 percent versus their previous provider by paying only for the features they actually use. The rest of the effect shows up quickly too: trusted returning devices skip re verification entirely, disposable numbers and known fraud patterns get stopped before they reach the product, and there is one integration to maintain instead of three.

Where to Start

If you're already using Prelude Verify, Auth is the natural next layer, built on the same signals you're already collecting. If you're starting from scratch, Auth, Verify, and Notify work as one platform, one invoice, one trust profile per user.

Read the full documentation to see the integration guide, or start for free to try it against your own signup flow.